Raft实现报告（九）

读者需要知道先前介绍的日志复制机制

从该机制我们知道，一旦一个日志条目存储在了大多数服务器上，leader就知道当前任期的条目已经提交了。如果leader在提交一条日志条目之前宕机了，未来的leader会企图完成该日志条目的复制工作，但是，一个ledaer没办法立刻知道先前时刻的条目是否已经提交了，即便日志条目已经存在大多数服务器上。对好对照Raft实现报告（八）的那张图去看。

为了减少这种问题的出现，Raft永远不会通过计算副本来提交先前任期的日志条目，只有来自leader当前的任期的条目会通过计算副本来提交，当来自当前term的日志条目被以这种方式提交了之后，由于Log Matching 特性，所有先前的条目会被间接的一起提交了，这一点在之前的报告里，也提到过。

在某些情况下，leader可以安全的断定旧的日志条目已经提交了（例如，该条目已经存储在每台服务器上了），但是Raft为了简单，采用了更加保守的方法。

Raft之所以在提交的时候产生了这种额外的复杂性，是因为leader从之前的term中复制条目的时候，日志条目会保留其原始term的期号。在其他共识算法中，如果一个新的leader从先前任期复制日志，该行为必须带上它当前任期的期号，并不像raft这样日志会保留原始期号。Raft的方法让推理分析日志条目变得更加容易，因为即便是任期变化了，随着时间推移，日志仍然保持原来的任期编号，此外，与其他的算法相比，raft中新的leader发送的前任期日志条目更少。（其他的算法必须发送冗余的日志条目然后重新编号，才能提交）