1、raft协议是什么？

分布式系统之于单机系统，优势之一就是有更好的容错性。

• 比如，一台机器上的磁盘损坏，数据丢失，可以从另一台机器上的磁盘恢复（分布式系统会对数据做备份）
• 比如，集群中某些机器宕机，整个集群还可以对外提供服务

这是如何做到的？比较容易的一个想法就是备份（backup）。一个系统的工作模是：接受客户端的command，系统进行处理，将处理的结果返回给客户端。由此可见，系统里的数据可能会因为command而变化。

实现备份的做法之一就是复制状态机（Repilcated State Machine，RSM），它有一个很重要的性质——确定性（deterministic）：

• 如果两个相同的、确定性的状态从同一状态开始，并且以相同的顺序获得相同的输入，那么这两个状态机将会生成相同的输出，并且结束在相同的状态

也就是说，如果我们能按顺序将command作用于状态机，它就可以产生相同的状态和相同的输出

那么一个状态机如何实现呢？如下图所示（来自raft协议）：

image

上图中，每个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的过程是一个正确的过程。

image

在（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,如下图的情况：

image

raft的解决方法就是two phase approch，引入一个过度配置，称为共同一致状态。具体的做法和图示：

• leader收到更新配置请求的时候，产生一个（old,new）entry，并append进日志
• 通过rpc让follower追加这条日志
• 如果顺利，将这条日志commit
• 产生new entry, append到日志
• 通过rpc让follower追加
• 如果顺利commit，从而完成新配置的生成

image

　考虑上述过程：

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