Почему Рафт должен предоставлять право голоса, когда голосование за является кандидатом?

Question

Я не уверен, правильно ли я понимаю детали RPC RequestVote в Raft.

В статье говорится

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)

При каких обстоятельствах voteFor == candidateId удерживать, когда получатель получает RequestVote RPC? Кандидат не будет отправлять другой RPC RequestVote в течение того же срока. Если начнутся новые выборы, срок увеличится, поэтому получатель должен преобразовать в последователя и 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 

Хотя это, очевидно, неправильно, похоже, все работает нормально, то есть выборы лидера и отправка запроса на голосование могут работать стабильно.

Любые советы будут с благодарностью и заранее спасибо

Answer 1

Я считаю, что это просто проверка работоспособности на предмет дублирования сетевых пакетов. В идеальном случае только один RequestVoteRPC сообщение будет достигнуто в течение одного семестра.

Но поскольку сеть может находиться во многих состояниях, которые далеки от идеальных, сетевой пакет, содержащий RequestVoteRpc может дублироваться, поэтому вам также нужно позаботиться об этом так же, как вы проверяете, предоставил ли пэр вам уже голос, чтобы вы не учитывали его дважды.