当 voteFor 是 candidateId 时，为什么 Raft 应该授予投票权？

Question

我不确定我是否正确理解了 Raft 中的 RequestVote RPC 细节。

论文里说

Receiver implementation:

1. Reply false if term < currentTerm (§5.1)

2. If votedFor is null or candidateId, and candidate’s log is at least as up-to-date as receiver’s log, grant vote (§5.2, §5.4)

接收方收到RequestVote RPC时，在什么情况下voteFor == candidateId成立？候选人不会在同一任期内发送另一个 RequestVote RPC。如果它开始另一次选举，任期会增加，所以接收者应该转换为追随者并且 voteFor is null.

在我之前的Raft实现中，我的逻辑是这样的：

If votedFor is null or me, and candidate’s log is at least as up-to-date as receiver’s log, grant vote

虽然明显是错误的，但似乎工作正常，即leader选举和发送requestVotes可以稳定工作。

任何建议将不胜感激，并提前致谢

Answer 1

我相信这只是针对网络数据包重复的健全性检查。在理想情况下，一个期限内只有一条 RequestVoteRPC 消息会到达对等方。

但是由于网络可能处于许多远非理想的状态，因此包含 RequestVoteRpc 的网络数据包可能会被复制，因此您还需要像检查是否同行已经给了你一票，所以你不要算两次。

当 voteFor 是 candidateId 时，为什么 Raft 应该授予投票权？

Why Raft should grant vote when voteFor is candidateId?

consensus

raft

leader-election