raft协议小结
1、raft协议是什么?
分布式系统之于单机系统,优势之一就是有更好的容错性。
- 比如,一台机器上的磁盘损坏,数据丢失,可以从另一台机器上的磁盘恢复(分布式系统会对数据做备份)
- 比如,集群中某些机器宕机,整个集群还可以对外提供服务
这是如何做到的?比较容易的一个想法就是备份(backup)。一个系统的工作模是:接受客户端的command,系统进行处理,将处理的结果返回给客户端。由此可见,系统里的数据可能会因为command而变化。
实现备份的做法之一就是复制状态机(Repilcated State Machine,RSM),它有一个很重要的性质——确定性(deterministic):
- 如果两个相同的、确定性的状态从同一状态开始,并且以相同的顺序获得相同的输入,那么这两个状态机将会生成相同的输出,并且结束在相同的状态
也就是说,如果我们能按顺序将command作用于状态机,它就可以产生相同的状态和相同的输出
那么一个状态机如何实现呢?如下图所示(来自raft协议):
上图中,每个RSM都有一个replicated log,存储的是来自客户端的commands。每个RSM中replicate log中commads的顺序都是相同的,状态机按顺序处理replicate log中的command,并将处理的结果返回给客户端。由于状态机具有确定性,因此每个状态机的输出和状态都是相同的。
上图中有一个模块——Consensus Module刚刚没有提及。这个模块用于保证每个server上Log的一致性!
- 如果不做任何保障,直接将commad暴力写入,一旦服务器宕机或者出现什么其他故障,就会导致这个Log丢失,并且无法恢复。而出现故障的可能性是很高的,这就导致系统不可用
- raft就是Consensus Module的一个实现
因此,raft是一致性协议,是用来保障servers上副本一致性的一种算法。
2、raft协议原理
下面将看论文时我认为的重要点进行记录。
raft协议遵循的性质
-
Election Safty
- 每一个任期内只能有一个领导人
- Leader Append-Only
- leader只能追加日志条目,不能重写或者删除日志条目
- Log Maching
- 如果两个日志条目的index和term都相同,则两个如果日志中,两个条目及它们之前的日志条目也完全相同
- Leader Completeness
- 如果一条日志被commited过,那么大于该日志条目任期的日志都应该包含这个点
- State Machine Safety
- 如果一个server将某个特定index的日志条目交由状态机处理了,那么对于其他server,交由状态及处理的log中相同index的日志条目应该相同
2.1 如何保证Election Safty
raft中,只要candidate获得多数投票,就可以成为领导人。follower在投票的时候遵循两个条件:
- 先到先得
- cadidate的term大于follower的term,或者两个term相等,但cadidate的index大于follower的index
对于选举结果:
- 如果票被瓜分,产生两个leader,这次选举失效,进行下一轮的选举
- 只有一个leader的情况是被允许的
这里重要的一点是:如何保证在有限的时间内确定出一个候选人,而不会总是出现票被瓜分的情况?raft使用了一个比较优雅的实现方式,随机选举超时(randomize election timeouts)。这就使得每个server的timeout不一样,发起新一轮选举的时候,有些server还不是voter;或者一些符合条件的candidate还没有参加下一轮。这种做法使得单个leader会很快被选举出来。
2.2 如何保证Log Matching
Leader在进行AppendEntry RPCs的时候,这个消息中会携带preLogIndex和preLogTerm这两个信息,follower收到消息的时候,首先判断它最新日志条目的index和term是否和rpc中的一样,如果一样,才会append.
这就保证了新加日志和其前一条日志一定是一样的。从第一条日志起就开始遵循这个原理,很自然地可以作出这样的推断。
2.3 如何保证Leader Completeness
这个在raft协议中是有完整证明的,这个证明比较简短,用反正法,我在看的时候加了一些标注。
假设leaderU是第一个没有包含leaderT中commitT点(T<U)
- 基于这个假设,一个事实是,开始选举的时候,U中就不包含T中的commit点
- 由于leaderT有commitT点,说明在任期T内,有大部分的follower都有commitT的点。这就说明,一定存在一个voter,它包含了commitT点,并且它投票给了leaderU
- 如果leaderU和这个voter有相同的term,那么leaderU的日志长度一定大于等于这个voter(否则会因为index小而被拒绝投票),那么leaderU肯定包含了voter的所有信息(这个是由Log Matching的属性决定的,它们包含有相同的term,因此相同index的日志条目肯定相同),leaderU中肯定包含commit点,这与假设矛盾
- 如果leaderU和这个voter的term不同,那么leaderU的日志index一定大于等于voter的index。也就是说,为leaderU添加最后一条entry的那个leader因该已经包含提交的日志(这是因为leaderU的leader的term>leaderU的term>voter的term,而leaderU是的一个不符合条件的任期,所以leaderU的leader应该是符合条件的,肯定就包含了voter的commit点),即包含commit点,根据Log Maching的原则,leaderU里面一定包含了这一点,这与假设矛盾
- 因此,leader completeness是可以保证的
2.4 raft协议中有一个约定,不能提交之前任期内log entry作为commit点。这是为什么?
这个问题主要是raft协议中commiting entries from previous term部分看的时候有点困惑,开始误解成了这个约定是用来保证之前任期内已经被复制到大多数server却没有被提交的日志在新的仍期内不会被覆盖。
实际上,论文中的figrure8的过程是一个正确的过程。
在(c)中,index=2并没有被提交,在(d)中被复制了是一个正确的做法。论文想阐述的是:如果在(c)中,leader提交了这个之前任期内的entry,在(d)中依然会被覆盖,也就是说被commit的entry覆盖了,这是一个错误!因此约定“can not commit entries from previous term”
2.5 cluster membership changes
如果集群的配置发生了变化,例如,新加入几台server,挂掉几台server。这是会影响选举的。
- 例如,如果新增了服务器,却没有更新原来server的配置,会导致leader election只有老机器在参与
- 又比如,如果直接将新的配置更新到leader这个方法是有问题的。如果leader没有及时通知到所有的服务器,那么存在部分server是老配置,部分server是新配置,从而可能会产生两个leader,如下图的情况:
raft的解决方法就是two phase approch,引入一个过度配置,称为共同一致状态。具体的做法和图示:
- leader收到更新配置请求的时候,产生一个(old,new)entry,并append进日志
- 通过rpc让follower追加这条日志
- 如果顺利,将这条日志commit
- 产生new entry, append到日志
- 通过rpc让follower追加
- 如果顺利commit,从而完成新配置的生成
考虑上述过程:
- 1,2两个阶段,如果过程中出现问题,大多数情况old成为新的leader
- 因为此时,拥有(old,new)entry的server并不是大多数
- 如果说,已经复制给大多数server,只是未提交,那么(old,new)是有可能被选为leader,不过这没有什么太大的影响,因为新的leader在被选之后,会发送一条no-op的rpc,这个时候(old,new)就会被提交。重要的是,此时也仅有可能一个leader被选出,old不肯那个被选举为leader.
- 3,4,5阶段,大多数情况(old,new)成为leader,例外与上条类似
- 5阶段就是new成为leader
2.6 log过长或日志回放时间过长怎么办?
此时就需要做log compaction
raft采用的方法是写时复制的snapshot(写是复制在linux中可以通过fork来完成)
-
- 写时复制主要是处于性能考虑的,如果state machine数据太多,snapshot将会耗费大量的时间,也许会导致系统可用性大大降低