5.4.2 提交之前任期的日志条目

正如5.3节中描述的那样，只要一个日志条目被存储在了大多数的Server上，Leader就知道属于当前任期的条目已经提交了。如果Leader在提交之前就崩溃了，将来的Leader会尝试着继续完成复制日志。然而，新Leader并不能马上确定，一个来自前一任期的条目已经被提交，虽然该条目已经存储到了大多数Server上。图-8说明了一种情况，一个存储在了大多数Server上的日志条目仍然被新上任的Leader覆盖了。

图-8：如图的时间序列说明了为什么 Leader 不能通过之前任期的日志条目判断它的提交状态。在(a)中，S1 是 Leader 并且部分复制了索引2上的日志条目。在(b)中 S1 崩溃了；S5 通过 S3、S4 和自己的投票赢得了选举，并且在索引2上接收了另一个日志条目。在(c)中 S5 崩溃了，S1 重启了，通过 S2、S3 和自己的投票赢得了选举，并且继续索引2处的复制，这时任期2的日志条目已经在大部分服务器上完成了复制，但是还并没有提交。在(d)中，如果S1崩溃了，S5 会通过 S2、S3、S4 的投票成为 Leader，然后用它自己在任期3的日志条目覆盖掉其他 Server 的日志条目。然而，如果 S1 在崩溃之前，它当前任期在大多数 Server 上复制了一个日志条目，就像在(e)中那样，那么这个条目就会被提交（S5 就不会赢得选举）。在这时，之前的日志条目就会正常被提交。

为了消除图-8中描述的问题，Raft从来不会通过计算复制的日志条目数，来提交之前任期的日志条目。只有Leader当前任期的日志条目才能通过计算数目来进行提交。一旦当前任期的日志条目以这种方式被提交，那么由于日志匹配原则（Log Matching Property），之前的日志条目也都会被间接的提交。在某些情况下，Leader可以安全的知道一个旧的日志条目是否已经被提交（例如，通过观察该条目是否存储到所有Server上），但Raft使用了一种更加保守的方法来简化问题。

因为当Leader从之前任期复制日志条目时，日志条目保留了它们上一个任期的编号，这使得Raft在提交规则中增加了额外的复杂性。在其它的一致性算法中，如果一个新的Leader要复制之前任期中的日志条目，它必须要使用新的任期编号。Raft采用的方式，使得判断日志条目更加容易，因为它们在整个日志文件中一直维护着同样的任期编号。另外，和其它的一致性算法相比，Raft算法中的新Leader会发送更少的之前任期的日志条目（其他算法在提交之前，必须要发送冗余的日志条目以便记住它们）。