1

我一直在https://youtu.be/vYp4LYbnnW8?t=3244观看 Raft 算法视频，但不清楚一种情况。

领袖选举

在任期 4 的领导者选举中，如果节点 s1 在 s3 之前广播 RequestVote，那么节点 s2、s4 和 s5 会投票给它，而 s3 不会。然后节点s3向其他人广播RequestVote，它如何获得其他人的投票？

我能弄清楚的处理这种情况的一种可能方法是：

  1. 如果节点 s1 收到 s3 的拒绝，发现 s3 的日志比自己更新，即使获得多数票也不将自己设置为领导者
  2. 至于其他节点，他们会记住他们投票的leader信息，如果有新的投票请求（更大<lastTerm, lastIndex>），他们会投票给更大的节点<lastTerm, lastIndex>。

在这两种情况下，最终节点 s3 都会获得所有其他人的投票，并将自己设置为领导者。我不确定我的猜测是否正确。

4

1 回答 1

2

（在我发表评论之前，请注意，没有可能提交条目 #9。没有迹象表明已提交哪些日志条目，但此讨论适用于已提交的 #s 1-8 中的任何一个。）

简而言之，s3 不会成为领导者，s1 会成为领导者，因为它获得了多数选票。如果您担心条目#9 会丢失，那是真的，但它并没有被提交。

从§5.3 开始：

在 Raft 中，领导者通过强制追随者的日志复制自己的日志来处理不一致。这意味着跟随者日志中的冲突条目将被领导者日志中的条目覆盖。

评论您对情况的处理。

1，如果节点s1收到s3的拒绝，发现s3的日志比自己更新，即使获得多数票也不设置自己为leader

它可以这样做，但它会使故障转移花费更长的时间，因为 s3 将不得不以不同的超时时间再次尝试，并且您会进入竞争条件，即 s1 总是在 s3 之前广播 RequestVote。但同样，删除 s3 拥有的多余条目总是安全的。

§5.3 的最后一段讨论了如何使用这个简单的、基于超时的选举过程，而不是对节点进行排名并选择最佳节点。我同意这个结果。更简单的协议更健壮。

2、对于其他节点，他们记住自己投票的leader信息，如果有新的投票请求（较大的<lastTerm, lastIndex>）来，他们投票给较大的节点<lastTerm, lastIndex>。

这是严格禁止的，因为它破坏了领导人选举。也就是说，如果你有这个，你会经常选举多个领导者。这是不好的。我怎么强调都不过分。糟糕，糟糕，糟糕。

于 2018-09-10T22:25:46.950 回答