distributed-system - 在 Raft 分布式共识中，我应该将 votedFor 设置为什么？

Question

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

启动时 term是 0 和 votedFor是 null

服务器选举超时后，该服务器成为候选人，增加其 term按 1，并设置其 votedFor给自己。

当服务器收到 RequestVote带有 term 的 RPC比自己高，应该更新term到观察到的数字，然后更新 votedFor如果接收服务器有 votedFor，则发送给发件人的 null它的日志并不比发件人的日志更新。

当候选人收到 AppendEntries RPC，以及发件人的 term高于或等于自己的，候选人应更新其 term给发件人的 term然后设置它的 votedFor给发送者并让它的状态成为跟随者，从而承认发送者是其合法的领导者。

在所有其他情况下，当服务器收到任何包含 term 的 RPC 请求或响应时高于自己的，应该设置自己的term到接收服务器的 term并设置 votedFor至 null .

一起，做这些构成term的仅有的5种方式和 votedFor在正确的 Raft 实现中设置，这些案例是否正确总结？我对此感到困惑，因为论文只提到在某些时候节点会转换为关注者，但没有指定是否 votedFor应该是具有较高项的发件人的值或 null .我担心案例 4 是错误的，应该是这样的:在 AppendEntries如果发送者的任期更大，那么接收者应该更新他们的 term到发件人的，然后设置 votedFor给发送者，无论接收者是 Follower、Candidate 还是过时的 Leader。

Answer 1

正如您在原始论文图 2 的“所有服务器的规则”中所见:

If RPC request or response contains term T > currentTerm:

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

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

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