(Прежде чем комментировать, учтите, что существует NO возможный способ фиксации записи №9. Нет указания на то, какие записи журнала фиксируются, но это обсуждение работает с любым из #s 1-8 как совершено.)
Короче говоря, s3 не становится лидером, s1 делает, потому что получает большинство голосов. Если вы обеспокоены тем, что запись № 9 будет потеряна, это правда, но она все равно не была зафиксирована.
С §5,3 :
В Плоте лидер обрабатывает несоответствия, заставляя
журналы подписчиков дублируют его собственные. Это означает, что
конфликтующие записи в журналах подписчиков будут перезаписаны
с записями из журнала лидера.
Чтобы прокомментировать, как вы справились с ситуацией.
1, если узел s1 получает отклонение от s3 и обнаружил, что журнал s3 новее, чем он сам, и не устанавливает себя в качестве лидера, даже если он получает большинство голосов
Это может сделать это, но для восстановления после отказа потребуется больше времени, потому что s3 придется повторить попытку с другим таймаутом, и вы попадаете в состояние гонки, когда s1 всегда передает RequestVote раньше, чем s3. Но опять же, всегда безопасно удалить лишние записи, которые есть у s3.
В последнем параграфе §5.3 говорится о том, как этот простой, основанный на тайм-ауте процесс выбора использовался вместо ранжирования узлов и выбора лучших. Я согласен с результатом. Более простые протоколы более надежны .
2, Что касается других узлов, они запоминают информацию лидера, за которого они проголосовали, если приходит новый запрос на голосование (с большим <lastTerm, lastIndex>), они голосуют за узел с большим <lastTerm, lastIndex>.
Это строго запрещено , потому что это разрушает выборы лидера. То есть, если у вас это есть, вы очень часто будете выбирать нескольких лидеров. Это плохо. Я не могу не подчеркнуть, насколько это плохо. Плохо, плохо, плохо.