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日志写入的过程：
- Propose， Leader写入一条日志，准备开始同步, Leader发起Propose；
- Append： Leader在Propose后会将写入请求转换为写入日志，存到日志文件中；(日志组成:region_id + 序号+数据组成，日志存储在本地的RocksDB实例中)；
- Replicate: Leader将日志分发给follower；follower收到日志后写入到本地存储中（Append）； 返回消息给Leader确认；
- Commited: 当多数节点都返回了Append成功的消息后，Leader认为写入成功；此时可以保证Raft rocksdb的日志不丢失；（区别于用户的commit）
- Apply： Leader将数据写入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