背景

为了增加一致性算法的正确性，即日志复制的正确性，Raft 又增加了一些安全机制，也就是打补丁。

我们一起来看看。

选举的限制

首先说结论，Raft 保证所有之前的任期号中已经提交的日志条目在选举的时候，都会出现在新的领导人中。不需要额外传送这些日志给领导人 —— 这意味了保证了数据的单向流动，即只从领导人传给跟随者，并且领导人从不会覆盖自身本地日志已经存在的日志条目。

如何实现？

Raft 使用投票的方式，来阻止一个候选人赢得选举 —— 除非这个候选人包含了所有已经提交的日志条目。

也就是说，如果想成为领导人，该节点必须包含所有已经提交的日志条目。

候选人为了赢得选举，必须联系集群中的大部分节点，那么，这些节点依据什么规则投票给候选者呢？

答：当候选者发送 RPC 给投票者时，RPC 中包含了候选人的日志信息，然后投票人会拒绝掉那些日志没有自己新的投票请求。

什么是新？
Raft 通过比较两个节点最后一条日志条目的索引值和任期号来定义谁的日志比较新。

通过这个规则来选举出日志最新的节点作为 leader。

首先，领导人如何提交自己当前任期内的日志条目？

答：当自己发送出去的日志 RPC 被大多数 follower 存储到了服务器上，那么就可以提交。

第二个问题：领导人如何提交之前任期内的日子呢

例如，如果这个 leader 在发送 RPC 之后、本地提交之前，崩溃了，怎么办？

在之前的介绍里，如果 leader 崩溃了，后面的新 leader 会继续尝试复制这条记录。

Raft 论文中关于这个规则的介绍：

但是，这将带来一个问题：一个领导人不能断定“一个之前任期里的日志条目被保存到大多数服务器上的时候” 就一定提交了。

下图将展示这种情况：

图 2

按照之前既有的规则：

在 (a) 中，S1 是领导者，部分的复制了索引位置 2 的日志条目。
在 (b) 中，S1 崩溃了，然后 S5 在任期 3 里通过 S3、S4 和自己的选票赢得选举，然后从客户端接收了一条不一样的日志条目放在了索引 2 处。
然后到 (c)，S5 又崩溃了；S1 重新启动，选举成功，开始复制日志。在这时，来自任期 2 的那条日志已经被复制到了集群中的大多数机器上，但是还没有被提交。
这时会发生 2 种情况：
4.1. 如果 S1 在 (d) 中又崩溃了，S5 可以重新被选举成功（通过来自 S2，S3 和 S4 的选票），然后覆盖了他们在索引 2 处的日志

4.2. 反之，如果在崩溃之前，S1 把自己主导的新任期里产生的日志条目复制到了大多数机器上，就如 (e) 中那样，那么在后面任期里面这些新的日志条目就会被提交（因为S5 就不可能选举成功）

注意：这两种情况在目前的规则下，都是会发生的！！！

但是，d1 的状态是错误的！！！

为什么？因为 d1 覆盖了 (c) 的日志！！！要知道，当（c）将日志复制到了大多数机器上，虽然 leader 没提交，但 follower 是有可能提交的。但是 d1 却将日志覆盖了，这将会导致 S2 和 S3 的状态机和日志不一致！！！

为什么会发生这个问题？

我们看看之前的选举规则，有没有漏洞。