【课程报告十】精读In Search of an Understandable Consensus Algorithm（3）

        文章的第4节阐述了如何确保每个状态机以相同的顺序执行相同的命令，因为在之前的方法中极有可能存在新的领导者将某些条目命令覆盖删除，因此给出了更为精确的选举规则。

        首先，要处理的便是新的领导者如何识别某些条目的缺失并把这些条目重新拾回进行同步。Raft使用了一种简单的方法，从选举的那一刻起，就选择那些拥有以前的条款中提交的所有条目的领导者，从而不需要将这些条目转移到leader身上。这使得日志条目只沿着一个方向流动，从领导者到追随者，领导者从不覆盖其日志中的现有条目。

        候选人不会赢得选举，除非其日志包含所有已提交的条目。RequestVote RPC实现了这个限制:RPC包含关于候选人日志的信息，如果投票者自己的日志比候选人的日志更新，那么投票者拒绝投票。而索引和term的标号则是判断谁的日志更新的准则，如果日志的最后条目具有不同的term，则具有后一个term的日志是最新的。如果日志以相同的期限结束，那么哪个日志较长，哪个日志是最新的。

        然后，第二个问题被提出：如果一个leader在提交一个条目之前崩溃，未来的leader将尝试完成该条目的复制。然而，一旦前一个term的条目存储在大多数服务器上，领导者就不能立即得出结论，认为该条目已经提交。

图8说明：a时，领导者S1发布条目2并进行同步，b时S1失败，S5成为领导者（大多数接收条目1）并接受条目3，在c时S5因为失败没有进行同步，S1作为领导者重启继续将条目2复制给S3（此时大多数复制了条目2），那么在情况d下，因为大多数原则S5仍然可以成为领导者，但复制的时条目3，而在情况e下，S1在失败前复制了条目4，S5无法成为领导者，日志中的所有前面的条目也被提交。

        为了解决图8中所示的问题，Raft从不通过对副本计数（大多数）来提交以前term的日志条目。只有来自领导者当前任期的日志条目是通过对副本计数（大多数）提交的;一旦以这种方式提交了当前term的条目，那么由于Log Matching Property，所有之前的条目都会间接提交。

Log Matching即之前提到的性质：如果不同日志中的两个条目具有相同的索引和term，则该日志在之前的所有条目中都是相同的。

        第3小节提出假设：某个term（T）的领导者提交该term但未被其他未来又可能成为领导者的节点复制，这里指定为某个term为U的节点（U>T）

给出完整的安全性论证：

1.在选举时，提交的条目必须不在未来领导者U的日志中

2.领导者T在大多数集群中复制了该条目T，而未来领导者U从大多数集群中获得了选票。因此，至少有一个节点(“投票者”)同时接受来自leaderT的条目T并投票给leaderU

3.在投票给未来领导者U之前，选民必须已经接受领导者T提交的条目T。

4.投票者在投票给leaderU时仍然存储该条目。

5. 投票人将自己的选票给了未来领导者U，因此未来领导者U的日志必须和投票人的日志一样是最新的。这导致了两个矛盾

6. 首先矛盾一，如果投票者和未来领导者U共享相同的上一个日志期限，那么未来领导者U的日志必须至少和投票者的日志一样长，因此它的日志包含投票者日志中的每个条目。因为投票者包含已提交的条目，而未来领导者U被假定为不包含（T）。

7. 矛盾二：如果6被否定，那么未来领导者U的最后一个日志项必须是比选民的大。此外，它比T大，因为投票者的最后一个日志项至少是T(它包含了从项T提交的条目)。创建了未来领导者U最后一个日志条目的较早的领导者必须在其日志中包含了提交的条目(T)。然后，根据日志匹配属性，未来领导者U的日志也必须包含提交的条目。

8. 因此，大于T的领导者必须包含在T前提交的所有项并提交了T。

9. 日志匹配属性Log Matching保证未来的领导者还将包含间接提交的条目，例如图8(d)中的索引2的条目3。

5.5阐述了跟随者和候选者的失败处理机制：如果一个跟随者或候选者崩溃，那么以后发送给它的RequestVote和AppendEntries rpc将会失败。Raft通过无限重试来处理这些失败;如果崩溃的服务器重新启动，那么RPC将成功完成。如果服务器在完成RPC之后但在响应之前崩溃，那么它将在重新启动后再次接收相同的RPC。

5.6阐述了Raft为了满足安全性对一些时间进行的约束：broadcastTime ≪ electionTimeout ≪ MTBF，其中broadcastTime是服务器向集群中的每个服务器并行发送rpc并接收其响应所需的平均时间;electionTimeout是选举超时;mtbf是单个服务器故障之间的平均间隔时间。

广播时间应该比选举超时时间小一个数量级，以便领导人能够可靠地发送阻止追随者开始选举所需的心跳消息。

选举超时应该比MTBF小几个数量级，这样系统才能稳步前进。当领导者崩溃时，系统将在大约选举超时时间内不可用，这只占总时间的一小部分。

广播时间可能从0.5ms到20ms不等，这取决于存储技术。因此，选举超时可能在10ms到500ms之间。典型的服务器mtbf是几个月或更长时间，这很容易满足时间要求。