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

Question

我正在尝试实现 Raft 共识算法。以下是我每次设置服务器状态的一般term理解votedFor：

1. 启动时term为 0 并且votedFor是null
2. 服务器选举超时后，该服务器将成为候选者，将其加term1，并将其设置votedFor为自身。
3. 当服务器收到一个比自己更高的RequestVoteRPC时，它应该将 更新为观察到的数字，然后更新到发送者，前提是接收服务器有一个of并且其日志不比发送者的日志更新。termtermvotedForvotedFornull
4. 当 Candidate 收到AppendEntriesRPC，并且发送者的状态term高于或等于自己的 RPC 时，Candidate 应该将其更新term为发送者的状态term，然后将其设置votedFor为发送者，并将其状态变为 Follower，从而承认发送者为其合法的领导者。
5. 在所有其他情况下，当服务器接收到任何包含term高于其自身的 RPC 请求或响应时，它应该将自己的值设置term为接收到的服务器的值term并设置votedFor为null。

这些一起构成了Raft 正确实现中仅有的 5 种方式吗？这些情况是否被正确总结term？votedFor我对此感到困惑，因为论文仅提到在某些时候节点将转换为追随者，而没有指定是否votedFor应该是具有较高术语或的发送者的值null。我担心情况4是错误的，应该是这样的：如果AppendEntries发送者的术语更大，那么接收者应该将其更新term为发送者的术语，然后设置votedFor为发送者，无论接收者是否是追随者、候选者或过时的领导者。

Answer 1

正如你在原论文图2的“Rules for All Servers”中看到的：

\n\n

\n

如果 RPC 请求或响应包含术语 T > currentTerm：

\n\n

设置 currentTerm = T，转换为 follower (\xc2\xa75.1)

\n

\n\n

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

\n\n

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

\n