raft学习（13）

raft学习（13）

5.4.2 从以前的terms中committing entries

正如5.3章所说的，leader知道它目前term的一个entry被committed，一旦entry被存储在大多数的servers节点中。如果leader在committing一个entry之前就crashed掉，未来的leader会尝试去完成entry的复制过程。然而，leader并不能立马得出以前term的entry被commited一旦它存储于大多数节点当中。图8阐明了这种情况，其中一个老的entry存在了大多数的节点中，然而它还是可以被未来的leader进行更改。

这里一个时间序列表明了一个leader为什么不能利用老的terms中的log entries来决定是否commit了。在a中，s1是leader，然后只有部分的follower复制了index2上的log entry。在b中，s1crashes掉，s5变成了term3中的leader（由s3， s4和它自己投票的），然后接受了一个在index2上不同的log entry。在c中，s5 crashes掉，s1重启被选为leader，然后继续它的复制。在这时候，term2的log entry被复制到大多数的servers上，单并不是committed的。如果s1 在d中crash掉，s5可能会继续成为leader，然后重写index2的entry变成它自己term3的entry。然而，正如e中，如果s1在crash之前复制了它当前term（也就是term4）的一个entry给大多数的servers，那么这个entry就是committed的（s5就不能取得election的胜利）。在这种情况下，之前所有log中的entries也会被committed。

为了解决图8中的问题，raft从来不通过数副本的方式来commit之前terms中的log entries。只有leader当前term的log entries通过数副本的形式来进行commit；一旦当前term的entry被以这种形式进行提交，那么由log匹配特性所有前面的entries都会间接地被提交。还有一些情况，比如leader可以安全地得出一个旧地log entry是committed的（例如，那个entry被存储在所有的server中），但是raft为了简单性采取更保守的手段。