本文主要是介绍【TiDB理论知识 05】TiKV-Raft协议,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
目录
一 概念
二 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秒
参考
三篇文章了解 TiDB 技术内幕 - 说存储 | PingCAP
这篇关于【TiDB理论知识 05】TiKV-Raft协议的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!