i am reading the raft paper.
To the 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)
in some situation , candidate's term is equal to leader' currentTerm,so how does the leader response to RequestVote rpc from a candidate?
Let's pick this apart in more human terms:
term < currentTerm
), ignore it.votedFor is null
), or if it's a vote for the same candidate we voted for last time in this term (votedFor == candidateId
), then grant the vote as long as the candidate log is up-to-date.Remember that leaders vote for themselves in a given term.
That means that for
term == currentTerm
, the leader will havevotedFor
equal to itself. This is not null, so the only way it will grant this vote is ifcandidateId
is itself - i.e., it's casting a vote for itself in the current term. In all other cases, it will not grant the vote.The high-level thing to remember (in fact, the key invariant in all of this) is that a server never votes more than once in the same term. Once it has made its vote for a term, it's final. And since a leader votes for itself, when it receives other requests for the same term it won't grant it.