5.4.1 选举限制

在所有以Leader为基础的一致性算法中，Leader最终必须要存储全部已经提交的日志条目。在一些一致性算法中，例如：Viewstamped Replication，即使一开始没有包含全部已提交的条目也可以被选为Leader。这些算法都有一些另外的机制来保证找到丢失的条目，并将它们传输给新的Leader，这个过程要么在选举过程中完成，要么在选举之后立即开始。不幸的是，这种方式大大增加了复杂性。Raft使用了一种更简单的方式来保证在新的Leader开始选举时，在之前任期的所有已提交的（Committed）日志条目都会出现在上边，而不需要将这些条目传送给Leader。这就意味着日志条目只有一个流向：从Leader流向Follower。Leader永远不会覆盖已经存在的日志条目。

Raft使用投票的方式来处理，避免一个没有包含全部日志条目的Candidate赢得选举，除非该Candidate的日志包含了所有已提交的条目。一个Candidate为了赢得选举，必须要同集群中的大多数Server进行通信，这就意味着，每一个已提交的日志条目至少在其中一个Server上出现。如果Candidate的日志至少和大多数Server上的日志一样新（up-to-date，会在后面经确定义），那么它将包含有所有已经提交的日志条目。RequestVote RPC实现了这个限制：这个RPC中包含Candidate的日志信息，如果它自己的日志比其它Candidate的日志要新，那么它会拒绝其它Candidate的投票请求。

Raft通过比较日志中最后一个条目的索引和任期号，来决定两个日志哪一个更新。如果两个日志的任期号不同，任期号大的更新；如果任期号相同，更长的日志更新。