一、TiKV概述

TiKV是TiDB的数据库的分布式存储引擎，数据以Region为单位进行复制和管理，每个

Region为单位进行复制和管理

每个Region会有多个Replica，这些Replica会分布在不同的TiKV节点上，其中leader负

责读和写，Follower负责同步Leader发过来的Raft log

二、关键问题

  • 如何保证同一个Region的多个Replica分布在不同的节点上？一台机器上启动多个TiKV

的实例存在的问题？

  • TiKV集群进行跨机房部署用于容灾的时候，如果一个机房掉线，如何保证不会丢失Raft

Group的多个Replica?

  • 添加一个节点进入TiKV集群之后，如何将其他节点的数据搬过来？

  • 如果一个节点短暂掉线时如何处理，如果节点长时间掉线，如何处理？

  • 如何调接Replica副本的个数

  • 并不是所有的Region都被经常访问，可能热点数据只在少数的几个Region上

  • 集群在做负载均衡的时候，需要搬迁数据，这种数据的迁移能否不占用大量的网络带

宽、磁盘IO和CPU

三、系统调度需求

1、分布式高可用存储系统的要求

  • 副本数量不能多也不能少

  • 副本需要分布在不同的机器上

  • 新增加节点之后，其他节点上的副本如何迁移过来

  • 节点下线时，需要将该节点的数据迁移走

满足这些需求后系统具有多副本的容错、动态的扩容/缩容、容忍节点掉线和自动故

障恢复的功能

2、需要优化的需求

  • 整个集群leader的均匀分布

  • 维持每个节点的存储容量均匀

  • 维持热点分布均匀

  • 管理节点的状态，手动上线/下线节点、自动下线失效节点

满足这些需求后，系统的负载更加均匀，且更加方便的管理

四、系统调度的方案

满足3.2中的各种需求首先要收集一些信息、比如每个节点的状态，每个Raft Group

的消息，业务访问的统计

1、调度的基本操作

  • 增加一个Replica

  • 删除一个Replica

  • 将leader角色在一个Raft Group的不同Replica转换

恰好，Raft协议能够满足这三种需求，AddReplica、RemoveReplica、TransferLeader

三个基本操作丢被支持

2、信息的收集

（1）每个TiKV的节点会定期向PD汇报节点的整体信息

Store与PD直接存在心跳包，一方面 PD通过心跳包检测每个Store是否存活和是否有

新加入的Store信息

心跳包中会包含整个节点的Store信息，具体有如下几项：

  • 总磁盘容量

  • 可用磁盘容量

  • 承载的Region的数量

  • 数据写入的速度

  • 发送接收SnapShot的数量，Replica之间会通过SnapShot同步数据

  • 节点是否过载等等

(2)每个Raft的Group的leader会定期向PD汇报信息

每个Raft Group和Leader之间存在心跳包，心跳包的具体信息如下Leader的位置、

Followers的位置、掉线的Replica的数目数据写入或者读取的速度

3、调度的策略

(1)一个Region的Replica数量正确

当PD通过某个Region Leader的心跳包发现这个Region的Replica数量不满足要求时，

需要通过Add/Remove Replica操作Replica数量,出现这种情况的原因是:

  • 某个节点掉线，数据丢失，导致一些Region的数量不足

  • 某个掉线节点又恢复业务，自动接入集群，但是之前已经补充了Replica

  • 副本策略被调整，修改了最大Replica的配置

(2)一个Raft Group中的多个Replica不在同一个位置

  • 多个Replica不会在同一个节点上，避免单个节点的失效导致多个Replica丢失

  • 多个节点部署在同一台物理机器上

  • TiKV节点分布在多个机架上，当单个机架掉电时，能够保证系统可用性

  • TiKV节点分布在多个IDC中，在单个机房掉电时，也能保证系统可用

(3)副本在Store之间的均匀分布

副本数量的均衡会使得总体的负载更均衡

(4)Leader数量在Store之间的均匀分布

Raft协议尧要读取和写入都通过Leader进行，计算负载主要在Leader上面，PD尽

可能将leader分散开

(5)访问的热点数据在Store时间均匀分布

每个Store以及Region Leader在上报信息的时候携带了当前访问负载的信息，PD会

检测出访问热点且将其在节点之间分散开

(6)各Store的存储空间占用大致相同

每个Store启动的时候都会制定一个Capacity参数，表明这个Store的存储空间上限PD

在做调度的时候会考虑节点的剩余空间

(7)控制调度的速度，避免影响正产业务

调度操作比较耗费CPU、内存、磁盘IO和网络带宽。一般情况下会对速度进行控制，

当然也可以加快调度的速度

(8)支持手动下线节点

当通过pd-ctl手动下线节点后，PD会在一定的速率控制下，将节点上的数据调度走。

当调度完成后便会将这个节点置为下线状态

4、调度实现的具体过程

PD不断的通过Store或者Leader的心跳包收信息，获得整个集群的数据，根据这些信息

以及调度策略生成调度操作系列，将需要进行的操作返回给Region leader，并在后面的心

跳包中检测结果