拉夫特的论文说：
Raft使用投票过程来阻止候选人赢得除非其日志包含所有提交的条目。候选人必须联系集群的大多数成员才能当选意味着每个提交的条目必须至少存在于这些服务器。如果候选人的日志至少是最新的其他人登录该多数，则它将保存所有提交的条目。RequestVote RPC实现了此限制：RPC包括有关候选人日志的信息，而选民否认如果其自己的日志比候选的日志更新，则其投票
然而，它如何保证始终存在甚至可选举的领导者(即与大多数集群一样最新的领导者(？
例如，假设我们有一个由三个服务器a、B、C组成的集群，其中a是领导者。第一个日志条目存储在A和B中，第二个日志条目保存在A和C中。然后A崩溃，B和C试图选出一个领导者。但在这一点上，没有大多数(即三分之二(服务器同时具有第一和第二条目。因此，领导人选举似乎永远不会发生(除非A重新启动，但Raft应该能够应对三分之一服务器的故障。(
本文定义了一个"日志匹配属性"；与此场景相关：
•[..]
•如果不同日志中的两个条目具有相同的索引和term，则前面所有日志都相同条目。
由于A和C都包含相同的第二个条目，因此C也必须包含第一个条目。这是可以确保的，因为：
第二个属性由AppendEntries执行的简单一致性检查来保证。发送AppendEntries RPC时，前导包含索引及其日志中紧接在前的条目的术语新条目。如果追随者在它的日志具有相同的索引和术语，然后它拒绝新条目。
在C拥有B拥有的条目之前，它将拒绝进一步的追加。因此，在您的场景中的某个时刻，C必须已经收到该条目，才能最终接受来自A.的新条目
因此，C是B和C之间最新的。(它将拒绝B的领导投票。(