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

Question

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

1. 启动时 term 为 0，votedFor 为 null
2. 服务器选举超时后，服务器成为候选人，将其 term 增加 1，并将其 votedFor 设置为自己。
3. 当服务器收到一个 RequestVote RPC 并且 term 比它自己的高时，它应该更新 term 到观察到的数字，然后更新 votedFor 到发件人当且仅当接收服务器的 votedFor 为 null 并且其日志不比发件人的日志更新。
4. 当Candidate收到一个AppendEntries RPC，并且发送者的term大于等于自己的，Candidate应该更新自己的term为发送者的[=10] =] 然后将其 votedFor 设置为发送者并使其状态变为 Follower，从而确认发送者为其合法领导者。
5. 在所有其他情况下，当服务器收到任何 RPC 请求或响应包含的 term 高于其自身时，它应将自己的 term 设置为接收到的服务器的 term 并且将 votedFor 设置为 null.

这些是否构成了在 Raft 的正确实现中设置 term 和 votedFor 的仅有的 5 种方式，这些情况是否正确总结？我对此感到困惑，因为该论文仅提到在某些时候节点将通过转换为跟随者而未指定 votedFor 应该是具有较高术语的发送者的值还是 null.我担心情况 4 是错误的，应该改为：在 AppendEntries 上，如果发送方的任期更大，则接收方应将其 term 更新为发送方的 term，然后设置 votedFor 发送给发送者，无论接收者是 Follower、Candidate 还是陈旧的 Leader。

Answer 1

在原论文图2的"Rules for All Servers"中可以看到：

If RPC request or response contains term T > currentTerm:

set currentTerm = T, convert to follower (§5.1)

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

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