在Raft分布式共识中，我将votedFor设置为什么？

Question

我正在尝试实施Raft一致性算法。以下是我对设置服务器状态的term和votedFor属性的所有时间的一般理解：

1. 启动时term为0，votedFor为null
2. 服务器选举超时后，服务器成为候选者，将其term递增1，并将其votedFor设置为自身。
3. 当服务器收到的RequestVote RPC比其自身高term时，它应将term更新为观察到的数字，然后将votedFor更新为发件人iff接收服务器的votedFor为null且其日志不是发件人日志的最新版本。
4. 当候选人收到AppendEntries个RPC并且发件人的term高于或等于其自己时，候选人应将其term更新为发件人的term然后将votedFor设置为发件人并让其状态成为追随者，从而确认发件人为其合法领导者。
5. 在服务器收到任何包含高于term的RPC请求或响应的所有其他情况下，它应将自己的term设置为收到的服务器的term并设置{ {1}}至votedFor。

在正确实施的Raft中，这些是null和term设置的唯一方法吗？这些情况是否正确汇总？我对此感到困惑，因为该论文仅提到在某些时候某个节点将转换为关注者，该关注者未指定votedFor应该是具有较高术语的发件人的值还是{{1} }。我担心案例4是错误的，应该是这样的：如果发件人的条件更大，则votedFor上，接收方应将其null更新为发件人的AppendEntries，然后设置term无论收件人是跟随者，候选人还是过时的领导者，都向发件人发送。

Answer 1

正如您在原始论文的图2中的“所有服务器的规则”中所看到的那样：

  

如果RPC请求或响应包含术语T＆gt; currentTerm：

     

设置currentTerm = T，转换为追随者（§5.1）

在这种情况下，您应该将votedFor重置为null。

因此，在规则3中，当服务器收到一个术语高于其自身的RequestVote RPC时，它应该将术语更新为观察到的数字，并将votedFor重置为{ {1}} （意味着在这种情况下，它将始终为请求服务器投票）。