Raft协议细节理解

分布式系统的一致性协议,Raft协议虽然说比paxos协议要简单,但是要理解也是有困难的。经过几天反复看raft协议的论文,然后仔细研读raft的代码感觉自己掌握了raft协议,其中理解最困难的是日志复制安全的那个限制吧。

1.raft要解决的问题。raft要解决的是分布式集群的一致性问题,而不是一个完善的存储系统,比如客户端当时没受到服务器返回,网络通路就挂了,过了几天还要服务器能自动给你返回,不是raft要解决的问题,这是由一个完善的系统的开发者要来解决的问题,不是raft的范围,raft只能确认你的请求被集群是否一致的接受,并且只要被提交确认接受就不可在相同位置被更改,只解决这些问题,我们看raft自己的客户端例子,他不解决返回异常的问题,所以读者不要扩大raft的解决范围

2. 两个rpc请求响应对 都有个current term成员,这样只要收到别人的current term比自己的current term大就更新自己的current term,比自己小拒绝这个投票,在下次自己发起投票的时候+1

3.选举限制5.4.1这节说的比较的term号是日志的term号不是节点的current term号,并且比较的日志并不一定是提交过的日志,是自己和对方所有的日志比较,包括提交和未提交的

4.提交的限制5.4.2这个图配上说明非常迷惑,其实他就是说如果leader的current term是4,你不能直接去提交自己的最大日志是term=2的那条日志,就算这个日志leader知道已经被所有机器接受也不能提交这个日志。如果你提交该日志就可能被s5覆盖,破坏raft的安全,当然不提交也会被s5覆盖,但raft只保证被提交日志的安全性;比current term小的日志term  ,Leader就不会去统计该日志是否被大多数节点接受。只有当有个新日志并且其必须term=4被大多数节点接受,然后可以直接提交这个term=4的新日志;这样可以导致之前的term=2的日志也被默认提交了,这点用数学归纳法证明。

5.leader提交了某日志在下次心跳的时候会通知其他节点也去提交这个日志,然后缓慢的通知节点一条一条的去应用日志

6.提交的日志,和应用的日志都是不一定存盘的,也就是节点挂了,再启动是有可能不知道自己提交了哪些日志,应用了哪些日志,至少raft协议和我看到的实现是没规定必须存盘

7.脏读问题,也就是读到了老版本的问题。如果集群出现了分区,由于老leader被废黜了自己却不知道,是会出现该问题的,因为读是没有日志的。解决这个问题,分为两步,一是新leader上任要提交空白日志去确认自己到底曾经提交了哪些日志(前面说过提交状态是不存盘的,还有可能是新leader以前是folloewer 还没来的及提交日志)。二是需要走一次心跳rpc,看自己的leader权限是否被废黜了。以上是一种分两步的方法。

还有一种方法是依赖时序的lease机制,这个tikv里有对脑裂的脏读问题详细描述。

8.日志rpc的prevlogindex当leader刚发出日志心跳的时候,就是等于自己的最大的日志索引,走过一次心跳后就为follower们的当前日志索引或当前日志索引之前的索引。本节点状态的nextindex就是follower们的想获得的日志索引,也就是follow的当前日志索引+1。投票rpc中的lastlogindex就是candidater自己的最大索引。这样索引的开始都是1而不是c语言用的0; leader发送的log entries是从nextindex发的,前面的日志是否存在只用比较prevlogindex prevlogterm一致就行了

9.客户端判断是否请求成功只用判断leader的该请求是否被提交就行了,不用去查询大多数节点,也不用判断是否被应用

10.应用状态机只是告诉用户可以把commit index存盘,只是可以,不一定非要存盘。应用状态机还有个工作就是将配置正在更改的状态清理。这个要及时,因为我看到的raft是不会处于配置更改状态,然后继续接受配置更改请求的

11.快照压缩:    1)各个节点自己独立打快照,2)打的快照只能包含已经提交的日志,3)快照中也要包含最后一次的配置,4)打完快照就可以丢弃之前的日志了,5)收到leader的快照丢弃自己的快照,6)follower收到leader的快照跟自己的commit index冲突也不要紧:因为leader最新,最牛逼,并且都是已经提交了的日志打快照

12.配置更改,论文花了很大篇幅介绍配置更改的时候并不阻塞客户端请求的方法。注意: 只要收到新配置该节点就立马采用新配置,不管是否被提交

   (1)一次添加多个节点比较麻烦,先说一次添加一个节点,我看的代码就是这样实现的,不会发生多个leader的情况,比如abcde 集群,e作为leader添加f 节点,e立马采用新配置感知了f的加入,这时候a想竞争leader:  (ab(c)def)如果想产生两个leader节点c 就要投两票,集合有交叉,所以不能产生两个leader。

  (2) 一次添加多个节点就比较麻烦了,开始是abc集群,现在添加de两个节点,就会发生ab可以投a作为leader,cde可以投c作为leader,解决这个问题分两阶段,第一阶段有个共同一致性状态Cold-new日志,提交这个日志前,集群想选leader必须获得新老配置两个各自的集群的大多数才能成功,提交日志也是必须获得双方的大多数,这样就不会产生两个leader,提交后再全部所有都切换为新配置。注意的是新老集群的任一方不得单独做决定,只有双方都确认了才能做决定。

在共同一致态,raft的规则是于之前说的不同的,

  1)日志被复制到所有节点

  2)新老都可以成为leader

   3)共同一致态要同时获得新老集群的大多数才能达成一致。

3个问题:

1)为了可用性,不要拖慢集群响应速度,新节点日志比较老,就先不给其投票权,但给其复制日志,等日志追上来了再给其投票权

2)leader是老集群的成员,leader自己被删除了或则说leader自己不是新集群一份子,这样leader只有在提交了Cnew后才下台,这是种奇怪的状态:他的复制日志,自己也不把自己计算大多数,只是复制提交日志。他提交完日志使命就结束了

3)被移除的pld集群的节点要竞争领导,导致正常leader被退位,使用最小超时时间,在这个最小超时时间内发起的投票直接拒绝,也不更新自己的current term;一个没有节点记录的选举,直接拒绝它的投票,并提示其下机

13.分区后的节点重连进集群,因为term比集群的大会干扰集群导致重新选举,而导致业务中断,这种情况采用zk的pre-vote机制。

>源码注释

推荐阅读更多精彩内容