目录
一 概念
二 raft共识算法对于TiKV的几个重要功能
1 Raft日志复制
1 Raft日志复制流程
2 名词解释
分层次理解TIKV
2 Raft Leader选举
集群初始状态时Leader选举流程
数据正在复制时Leader选举流程
初始化时的特殊情况
raft 参数与Tidb 参数对应关系
一 概念
leader :数据在TiKV中是以region为单位存储的，每个region默认有三个副本，其中一个副本的角色为leader，所有客户端的读写流量都是走leader的，follower是不参加读写的，leader会周期性的向follower发出心跳通知信息，同时也会把自己写的数据以日志的方式传递给其他follower
follower:被管理者，对其他服务作出相应，同时接受leader的日志并进行复制，如果长时间接收不到leader的通知信息，follower的角色就会转变为candidate（候选者），候选者会发起投票，告诉大家，leader不在了 ，你们要选我。candidate是由follower转变而来 ，转变的前提是leader长时间没有通知信息了
TiDB写数据的只写leader ，然后通过日志的方式，向其他follower进行复制。
数据在region中的存储：region是一个逻辑概念，是键值对的集合，region中是以key的排序的。region 中存储的kv达到96M后，会写下一个region。初始的region中的key连续的，region是一个左闭右开的区间。当region的大小达到144M之后，就会发生分裂split。当对region的数据进行大量删除时，region的大小过小时（可以自己设定这个值），也可以进行合并。
raft group:多个region 构成raft goup
multi raft :多个raft group构成multi raft
region中key数量过多的性能问题
当region的数量太多时，比如一个TiKV node中超过5w个region时 ，随之而来的就是管理成本很高，因为每个region需要定期的向PD进心跳的汇报。
二 raft共识算法对于TiKV的几个重要功能
1 Raft日志复制
1 Raft日志复制流程
当客户端TiDB server需要写入数据时，会把数据发送给TiKV中某个region 的leader角色,
第一步是 propose，会把写入请求转换为写入日志 Raft log。Raft log的格式：region号_日志序号.log，例如4_2.log { put key=3,name = nico}， 通过raft log的这种格式，可以明确确认操作的region以及日志的先后顺序。
第二步是 append， 然后就把raft log 存储在leader本地的Rocksdb中，进行持久化
第三步是 replicate，通过raft算法将日志发送给其他follower ,follower收到日志后也会持久化到本地RocksDB中，然后follower会返回append成功的消息，当大多数follower返回消息后，leader就会认为这条日志持久化成功，leader就会就行committed
每个TiKV node 中有两个RocksDB 一个存储KV 一个存储Raft log。
2 名词解释
通过名词再次理解
Propose：当客户端比如TIDB server，或者你自己开发的可以写入TiKV的客户端，写入的是一条日志Raft log
Append:Propose之后接收到Raft log，leader将Raft log持久化到rocksdb。目前之后leader的Raft log持久化了。
Repicate:将Leader的raft log复制到其他的副本所在的节点上。其他副本接受到日志后进行append
Committed: 超过半数的节点进行了append 并返回消息给follower ，就可以进行这条Raft log 进行了持久化不会丢失。这里的Committed是指的是raft log的Committed。这里的Committed不是事务中的，现在用户还是看不到这次日志所涉及的数据的修改。
Apply :将Raft log 转换 并写到 RocksDB KV中
分层次理解TIKV
为了实现持久化 ：使用了开源单机数据存储引擎Rocksdb，可以理解为一个巨大的key-value map。
为了实现数据高可用，避免单机故障：持久化之后要做数据多副本，数据多副本的一致性算法使用Raft 协议。
为了实现存储水平扩展：引入了Region
为了提高系统并发 写不阻塞读：引入MVCC层 ，数据多版本。
为了实现事务：引入Tranaction层
2 Raft Leader选举
Raft 共识算法中term：
term:时间时期的概念，官方定义 将时间分为一小段，每个Termd的长度不确定，他代表一段稳定的关系.举个例子：每个term就是一个恋爱关系，A和B 关系很好很稳定，这个term的长度就很长，如果A和B关系破裂了，A就进入下一个term。
集群初始状态时Leader选举流程
集群在刚开始创建的时候，没有leader ,每个region都是follower 。
每个region有个计时器 叫做 election timeout,假设为10秒，当超过这个时间，没有收到leader的心跳信息，就会认为集群中没有leader，那么这时候某个follower率先突破了election timeout这个时间（一般是150ms -300ms），要打破这种没有leader的关系。自己的角色转换为candidate，term 也加1。
然后想其他的follow发送投票的请求，其他的follower的term 比较小，会投票给term大。这样就产生了leader，进入下一段关系。
数据正在复制时Leader选举流程
此时的raft group中的region处于一种稳定的复制关系中 ，突然出现了宕机或者网络中断。当follower 超过某个时间没有收到leader的心跳信息时 ，这个时间为heartbeat time interval，就会认为leader挂了，然后就要起义，角色变为candidate，同时term +1 ,然后发起选举 ，term 小的会投投票给term比较大的region。
初始化时的特殊情况
多个region 都成为了candidate ,系统会重新发起投票，直到产生leader ,但是也有可能出现多次投票的状况，为了解决这个问题 Raft 共识算法引入了参数 random election timeout ,指定一个范围，比如100ms ~ 300ms ,这样大家都成为candidate的概率会降低很多。
raft 参数与Tidb 参数对应关系
ticks 代表多少个raft-base-tick-interval参数设置的时间单位
Election timeout 对应 raft-election-time-ticks * raft-base-tick-interval
Heartbeat time interval 对应 raft-heartbead-ticks * raft-base-tick-interval
raft-base-tick-interval 默认是1秒 raft-election-time-ticks = 5 ,则Election timeout 为5秒
参考文章来源：https://www.toymoban.com/news/detail-581054.html
三篇文章了解 TiDB 技术内幕 - 说存储 | PingCAP文章来源地址https://www.toymoban.com/news/detail-581054.html
到了这里，关于【TiDB理论知识 05】TiKV-Raft协议的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
