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将会耗费大量的时间,也许会导致系统可用性大大降低

 

 

 

 

 

 


  

  

 

  

       

 

posted @ 2017-09-13 01:25  Hoodwinked  阅读(...)  评论(...编辑  收藏