TIDB 中的REGION 是如何进行管理和协调的

熟悉TIDB 的同学都知道，TIDB 中的数据库存储节点是TIKV ，而这里TIKV 仅仅是数据的一个“物理”的存储地，并不是一个数据单位，TIKV的数据单元用Region来表达，那么一个TIKV 可以存储多个region，TIKV 和Region之间的关系是什么，之间的性能关系又是什么。

这里引入一个概念，raft group ,  在TIDB 中每一个region都是通过raft group, 来进行管理的。每个region 以及其副本都是通过 raftgroup来进行管理和协调的，多个 region 自然就有多个 raft group 来进行管理，这里给众多的raft group 一个名字 MultiRaft。

raft group 是通过并发处理机制来进行工作的，其中主要的功能有两个

1 normal

2 control

Normal 主要是处理自身region本身的任务，包含自身的消息队列，control主要的功能是针对整体REGION的状态以及调整进行工作。

借助官方的raftstore workflow 的图，整体处理region的系统组成了一个raftstore的模块，来针对整体模块的读写进行处理，region的状态进行处理， 并且定时的检查各个region的状态。

Raftstore 中存在两个机制，

1 raftBatchSystem 

2 applyBatchSystem

其中raftBatchSystem 处理与raft有关的一些工作，如日志的下发，日志的写入，和region 的状态变化。当日志写入后，applyBatchsystem会将日志变为实际的数据写入KV 的region中。

从上图我们可以看出，数据写入的步骤

1  日志先写入系统中

2  在确认日志写入到系统中后，应用日志将数据写入到KV的region中

3  在确认日志写入到系统中后，将数据发送给其他的KV的region副本

Raftstore 同时也控制Regionde  分裂和融合，根据数据的增加将数据分割成多个段落，或者合并相邻的两个段落的数据，这样的操作也会通过4个步骤来完成 raft  propose  commit  apply 四个流程。

除了完成上述的任务， 每个Region 本身也遵从RAFT协议，Leader region也有租约，raftstore在租约内收到请求会在Region leader节点进行写操作，再次以外raftstore还需要保证在进行region分割时基于key value的数据不会被拆分到2个region中，通过coprocessor 来保证。

总结：

TIKV 中包含raftstore模块， 主要功能负责日志的写入，数据的写入，数据的副本传输，region的分割和合并，保证数据读取和写入在租约期的安全，和region分割时key:value的完整性。