如果另一个节点先成为候选者，如何才能选出具有完整日志的节点？
How can a node with complete log can be elected if another becomes a candidate first?
我一直在 https://youtu.be/vYp4LYbnnW8?t=3244 观看 Raft 算法视频，但我不清楚一个情况。
在任期 4 的领导者选举中，如果节点 s1 在 s3 之前广播 RequestVote，则节点 s2、s4 和 s5 会投票给它，而 s3 不会。然后节点s3向其他人广播RequestVote，如何获得其他人的投票？
我能想到的处理这种情况的一种可能方法是：
- 如果节点s1收到s3的拒绝，发现s3的日志比自己更新，即使获得多数票也不要将自己设为leader
- 至于其他节点，他们记住他们投票的领导者信息，如果有新的投票请求（更大的
<lastTerm, lastIndex>），他们投票给更大的节点<lastTerm, lastIndex>。
在这两种情况下，最终节点 s3 都获得了所有其他人的投票，并将自己设置为领导者。不知道我的猜测是否正确。
（在我发表评论之前，请注意有 NO 可能的方式来提交条目 #9。没有指示提交了哪些日志条目，但是这个讨论与 #s 1-8 中的任何一个一起工作。）
简而言之，s3 没有 成为领导者，s1 成为领导者是因为它获得了多数选票。如果您担心条目 #9 会丢失，那是真的，但无论如何都没有提交。
来自§5.3：
In Raft, the leader handles inconsistencies by forcing
the followers’ logs to duplicate its own. This means that
conflicting entries in follower logs will be overwritten
with entries from the leader’s log.
评论你对情况的处理。
1, if node s1 receives the rejection from s3, and found out s3's log is newer than itself, and do not set itself as leader even though it receives majority of votes
它可以这样做，但它会使故障转移花费更长的时间，因为 s3 将不得不用不同的超时重试，并且您会进入 s1 始终广播的竞争状态在 s3 之前请求投票。但同样，删除 s3 的多余条目总是安全的。
§5.3 的最后一段讨论了如何使用这种简单的、基于超时的选举过程，而不是对节点进行排名并选择最佳节点。我同意这个结果。 更简单的协议更可靠。
2, As to other nodes, they remember the leader information they voted, if a new vote request comes (with bigger <lastTerm, lastIndex>), they vote for the node with bigger <lastTerm, lastIndex>.
这是严格禁止的，因为它会破坏领导选举。也就是说，如果你有这个，你通常会选出多个领导者。 这很糟糕。 我怎么强调都不为过。糟糕，糟糕，糟糕。
我一直在 https://youtu.be/vYp4LYbnnW8?t=3244 观看 Raft 算法视频，但我不清楚一个情况。
在任期 4 的领导者选举中，如果节点 s1 在 s3 之前广播 RequestVote，则节点 s2、s4 和 s5 会投票给它，而 s3 不会。然后节点s3向其他人广播RequestVote，如何获得其他人的投票？
我能想到的处理这种情况的一种可能方法是：
- 如果节点s1收到s3的拒绝，发现s3的日志比自己更新，即使获得多数票也不要将自己设为leader
- 至于其他节点，他们记住他们投票的领导者信息，如果有新的投票请求（更大的
<lastTerm, lastIndex>），他们投票给更大的节点<lastTerm, lastIndex>。
在这两种情况下，最终节点 s3 都获得了所有其他人的投票，并将自己设置为领导者。不知道我的猜测是否正确。
（在我发表评论之前，请注意有 NO 可能的方式来提交条目 #9。没有指示提交了哪些日志条目，但是这个讨论与 #s 1-8 中的任何一个一起工作。）
简而言之，s3 没有 成为领导者，s1 成为领导者是因为它获得了多数选票。如果您担心条目 #9 会丢失，那是真的，但无论如何都没有提交。
来自§5.3：
In Raft, the leader handles inconsistencies by forcing the followers’ logs to duplicate its own. This means that conflicting entries in follower logs will be overwritten with entries from the leader’s log.
评论你对情况的处理。
1, if node s1 receives the rejection from s3, and found out s3's log is newer than itself, and do not set itself as leader even though it receives majority of votes
它可以这样做，但它会使故障转移花费更长的时间，因为 s3 将不得不用不同的超时重试，并且您会进入 s1 始终广播的竞争状态在 s3 之前请求投票。但同样，删除 s3 的多余条目总是安全的。
§5.3 的最后一段讨论了如何使用这种简单的、基于超时的选举过程，而不是对节点进行排名并选择最佳节点。我同意这个结果。 更简单的协议更可靠。
2, As to other nodes, they remember the leader information they voted, if a new vote request comes (with bigger
<lastTerm, lastIndex>), they vote for the node with bigger<lastTerm, lastIndex>.
这是严格禁止的，因为它会破坏领导选举。也就是说，如果你有这个，你通常会选出多个领导者。 这很糟糕。 我怎么强调都不为过。糟糕，糟糕，糟糕。