В Raft распределенный консенсус, на что я устанавливаю votedFor?

Question

Я пытаюсь реализовать согласованный алгоритм Рафта.Вот мое общее понимание во всех случаях, когда мы устанавливаем атрибуты term и votedFor состояния сервера:

1. При запуске term равно 0, а votedFor равно null
2. По истечении времени ожидания сервера сервер становится кандидатом, увеличивает его term на 1 и устанавливает свой votedFor.
3. Когда сервер получает RPC RequestVote с* term выше, чем его собственный, он должен обновить term до наблюдаемого числа, затем обновить votedFor до отправителя, если получающий сервер имеет votedFor null и его журнал не болеена сегодняшний день, чем журнал отправителя.
4. Когда Кандидат получает AppendEntries RPC, а term отправителя выше или равен его собственному, Кандидат должен обновить свои term до отправителяterm затем установите его votedFor для отправителя и сделайте его состояние подписчиком, тем самым признав отправителя своим законным лидером.
5. Во всех других случаях, когда сервер получает любой запрос или ответ RPC, содержащий term приветБолее того, он должен установить собственный term для term полученного сервера и установить votedFor на null.

Вместе, все это составляет только 5 способовterm и votedFor установлены в правильной реализации Raft, и правильно ли суммированы эти случаи?Меня это смущает, потому что в статье упоминается только то, что в определенное время узел проходит преобразование в последователя, который не указывает, должно ли votedFor быть значением отправителя с более высоким сроком или null.Меня беспокоит, что случай 4 неверен и должен быть таким: вместо AppendEntries, если срок отправителя больше, то получатель должен обновить term до значения отправителя, а затем установить votedFor для отправителя, независимо от того,того, является ли получатель подписчиком, кандидатом или несвежим лидером.

Answer 1

Как вы можете видеть в «Правилах для всех серверов» на рисунке 2 оригинального документа:

Если запрос или ответ RPC содержит термин T> currentTerm:

setcurrentTerm = T, преобразовать в последователя (§5.1)

, и в этом случае вы должны сбросить votedFor на null.

В результате в вашем правиле 3когда сервер получает RPC RequestVote с термином, превышающим его собственный, он должен обновить термин до наблюдаемого числа , а также сбросить votedFor до null (что означает, что в этом случае онвсегда будет голосовать за запрашивающий сервер).