TiDB:Raft与Multi Raft

Leader：

• 集群的管理者
• 所有读写流量都是走Leader
• Leader会周期性向follower发出心跳信息；并且会将写的数据以日志的方式传递给其他follower；
• 当写入的数据成员过半，就认为写入成功；

Follower：

• 被管理者
• 对其他的服务作出响应
• 接受leader的日志；
• 如果长时间没收到leader的通知信息，就会将自己角色转换为后选择candidate，发起投票，票多着升级为Leader；

Region

• 是按照Key排序的连续的有序集合；
• 当Region插入达到96MB后会另起一个新Region；
• 初始化时,Region内的数据是连续的，Region中间也是连续的，左闭右开区间；region1: [1,1000), region2:[1000-2000),region3:[2000,3000)
• 随着数据的修改(例如UPDATE等)，Region大小会发生变化，当数据涨到144M的时候会自动分裂；当Region过小的时候会进行Region的合并；(分裂和合并的大小可以自定义)
• 一个Region构成一个Raft group，多个Region会形成多个Raft Group--Multi Raft
• 如果一个TiKV中的Region超过5W，会影响性能；

Raft 日志复制

Leader日志写入的过程：

1. Propose， Leader将写请求转化为Raft Log；
2. Append： 日志持久化日志， Leader在Propose后会将写入请求转换为写入日志，存到日志文件中；(日志组成:region_id + 序号+数据组成，日志存储在本地的RocksDB实例中)；
3. Replicate: Leader将日志分发给follower；follower收到日志后写入到本地存储中（Append）； 返回消息给Leader确认；
4. Commited: 当多数节点都返回了Append成功的消息后，Leader认为写入成功；此时可以保证Raft rocksdb的日志不丢失；（区别于用户的commit）
5. Apply：将数据写入TiKV中（一个TiKV中实际上有两个RocksDB，一个用于存储Raft Log,一个用于存储KV信息；）

Raft- Leader选举

 election_timeout默认10s，Raft在无主状态下多长时间会发起选举，如果follower 超过10s没收到Leader信息，该Region就会重新选举；第一个计时到时间的人首先称为candidate，并发起投票；

heartbeat_time_interval, Raft和follower的心跳间隔，默认10s；Leader和Follower的心跳检测，如果没收到心跳就会发起Vote

election_timeout > heartbeat_time_interval

election timeout:raft-election-timeout-ticks 

heartbeat time interva: raft-heartbeat-ticks

raft-base-tick-interval =1s

真实心跳时间: raft-heartbeat-ticks * raft-base-tick-interval