3

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

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

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

4

1 回答 1

4

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

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

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

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

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

于 2018-05-27T03:18:47.847 回答