熟悉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的完整性。
原文作者：AustinDatabases；如有侵权，请联系管理员删除。
最新文章
- 没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛
- MongoDB 大俗大雅，高端知识讲“庸俗” --3 奇葩数据更新方法
- MongoDB 学习建模与设计思路--统计数据更新案例
- 在被厂商围剿的DBA 求生之路 --我是老油条
- MongoDB 大俗大雅，高端的知识讲“通俗” -- 2 嵌套和引用
- MongoDB 大俗大雅，高端的知识讲“低俗” -- 1 什么叫多模
- OceanBase4.0 跟我学--分布式到底可靠不可靠，到底丢不丢数--终于学完了
- POLARDB 添加字段 “卡” 住---这锅Polar不背
- PostgreSQL 运维的难与“难” --上海PG大会主题记录
- PostgreSQL 变成"户外人士",后的自救的方法
