安全性
前面的实现报告讲述了Raft算法如何选出leader，如何复制日志条目。但仍有一些问题需要考虑，上述的机制到目前为止还不能十分充足的确保每个状态机能够精准的执行同样的命令在同样的顺序之下。
举个例子，当leader已经确认下发很多条命令的时候，也就是leader在commited状态的时候，有一个follower可能此时并不能正常工作，然后它可能会开始新的一轮选举然后重写这些条目，结果，不同的状态机可能会执行不同顺序的命令。
之后我们会设计诸多的限制，去避免这种意外选举的情况。这种限制可以确保leader在任意给定的term中能够包含所有之前term成功committed的日志条目。还会给予选举的限制，让commitment的过程更加的精确。最后将证明Leader Completeness特性，并展示他如何让状态机保持正确的行为
选举规定
在任意基于leader的共识算法中，leader必须最终存储所有的已确认日志条目。部分共识算法比如Viewstamped Replication, leader即使没有在最开始包含所有已确认的日志条目，都能被选出来，因为这不是基于leader的。而且Viewstamped并没有从理论上完整的解决选举问题。这些算法通过存储额外的信息去确认日志条目是否有丢失，然后将丢失的条目发送给新的leader，不好的是，这些结果需要考虑更多额外的东西，并且增加了复杂性。
Raft使用了更加简单的方法确保先前所有以提交的日志条目都能出现在leader的log当中，当节点成为leader的那一刻起，他就必须包含先前所有term的所有操作。这意味着raft的日志条目只有单一流向。从laeder发出向follwers复制，或覆盖。并且leader从来不会重写已经存在的日志条目
