Я пытаюсь реализовать согласованный алгоритм Рафта.Вот мое общее понимание во всех случаях, когда мы устанавливаем атрибуты term и votedFor состояния сервера:
- При запуске
term равно 0, а votedFor равно null - По истечении времени ожидания сервера сервер становится кандидатом, увеличивает его
term на 1 и устанавливает свой votedFor. - Когда сервер получает RPC
RequestVote с* term выше, чем его собственный, он должен обновить term до наблюдаемого числа, затем обновить votedFor до отправителя, если получающий сервер имеет votedFor null и его журнал не болеена сегодняшний день, чем журнал отправителя. - Когда Кандидат получает
AppendEntries RPC, а term отправителя выше или равен его собственному, Кандидат должен обновить свои term до отправителяterm затем установите его votedFor для отправителя и сделайте его состояние подписчиком, тем самым признав отправителя своим законным лидером. - Во всех других случаях, когда сервер получает любой запрос или ответ RPC, содержащий
term приветБолее того, он должен установить собственный term для term полученного сервера и установить votedFor на null.
Вместе, все это составляет только 5 способовterm и votedFor установлены в правильной реализации Raft, и правильно ли суммированы эти случаи?Меня это смущает, потому что в статье упоминается только то, что в определенное время узел проходит преобразование в последователя, который не указывает, должно ли votedFor быть значением отправителя с более высоким сроком или null.Меня беспокоит, что случай 4 неверен и должен быть таким: вместо AppendEntries, если срок отправителя больше, то получатель должен обновить term до значения отправителя, а затем установить votedFor для отправителя, независимо от того,того, является ли получатель подписчиком, кандидатом или несвежим лидером.