5.4.1 election的限制
在任何的基于leader的共识算法中，leader必须最终存储所有log entries的committed log。在某些共识算法中，例如viewstamped replication中，leader可以被选举即使它最初并没有包含所有的committed entries。这些算法包含额外的机制来认清missing entries然后将他传输给新的leader（在选举过程中或短暂的之后）。不幸的是，这导致了非常大的额外机制和复杂性开销。raft使用一个较为简单的方法来保证所有的以前的terms的commmited entries出现在新的leader选举完的moment上，并不需要传输这些entreis给leader。这意味着log entries只会单向流动，从leader到follower，并且leader并不会重写他们logs中的已有的entries
raft使用voting过程来防止candidate来获取election的胜利，除非它的log包含所有的committed entries。candidate必须联系cluster的大多数节点从而被选举，这意味着每个committed entry必须出现在至少这些servers中的一个。如果candidate的log是至少和其他任意大多数节点的log一样up-to-date的（up-to-date在下面更精确地定义），那么他就会拥有所有committed entries。requestVote rpc实现了这种限制：rpc包含了candidate log的信息，voter如果发现他们自己的log比candidate的log更up-to-date那么他们就拒绝该rpc
raft通过比较logs中的最后entries的index和term来决定两个logs谁是更加up-to-date的
如果logs有不同terms的last entries，那么有更later的term的就是更up-to-date的。如果logs以相同的term结束，那么哪个log更长就是更up-to-date的
