筏如何处理上一个提交的条目？
Jal*_*Jal 6 algorithm leader distributed consensus raft
在牛皮纸中，第5.4.2节
如果领导者在提交条目之前崩溃，则未来的领导者将尝试完成复制条目。但是，领导者一旦将其存储在大多数服务器上，就无法立即得出结论，即上一个条目的条目已提交。可能存在这样的情况，旧的日志条目存储在大多数服务器上，但仍可能被将来的领导者覆盖。
作者提到，要避免上述情况
为了消除类似图8中的问题，Raft决不通过对副本数进行计数来提交前项的日志条目。通过计算副本数，仅提交领导者当前任期的日志条目；一旦以这种方式提交了当前术语的条目，则由于“日志匹配”属性而间接提交了所有先前的条目。
但是会不会仍然出现同样的问题？
鉴于作者提供的以下情况
当S5当选领导者时，它只会查看其当前已提交的日志，(term3, index1)这将覆盖term2所有关注者中的条目。
让领导者查看自己的已提交日志如何解决该问题？
阅读此图片上的标题。(d) 和 (e) 都是对 (a)、(b) 和 (c) 生成的日志状态的可能解决方案。问题是，即使在 (c) 中条目 (2, 2) 被复制到集群的大多数，这说明当在 (d) 中选出 S5 时它仍然可能被覆盖。因此，解决方案是只允许节点提交自己术语中的条目。换句话说，在大多数节点上复制条目并不等于承诺。在 (c) 中，条目 (2, 2) 被复制到集群的大多数，但因为它不在领导者的任期内（至少 4），所以没有提交。但在 (e) 中，在领导者复制当前任期 (4) 中的条目后，可以防止 (d) 中的情况发生，因为 S5 无法再当选为领导者。