Как можно выбрать узел с полным журналом, если другой сначала станет кандидатом?

Question

Я смотрел видео с алгоритмом Рафта по адресу https://youtu.be/vYp4LYbnnW8?t=3244, но мне не ясно одно обстоятельство.

При избрании лидера на срок 4, если узел s1 транслирует RequestVote раньше, чем s3, тогда узлы s2, s4 и s5 будут голосовать за него, а s3 - нет. А затем узел s3 транслирует RequestVote другим, как он может получить голос других?

Один из возможных способов справиться с ситуацией, которую я могу понять:

1. если узел s1 получает отклонение от s3 и обнаруживает, что журнал s3 новее, чем он сам, и не устанавливает себя в качестве лидера, даже если он получает большинство голосов
2. Что касается других узлов, они запоминают информацию лидера, за которую проголосовали, если приходит новый запрос на голосование (с большим <lastTerm, lastIndex>), они голосуют за узел с большим <lastTerm, lastIndex>,

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

Answer 1

(Прежде чем я прокомментирую, учтите, что НЕТ возможного способа фиксации записи №9. Нет указания на то, какие записи журнала фиксируются, но это обсуждение работает с любым из #s 1-8 как фиксируемым.)

Короче говоря, s3 не становится лидером, s1 - потому что он получает большинство голосов. Если вы обеспокоены тем, что запись № 9 будет потеряна, это правда, но она все равно не была зафиксирована.

Из §5.3:

В Raft лидер обрабатывает несоответствия, заставляя журналы последователей дублировать свои собственные. Это означает, что конфликтующие записи в журналах подписчиков будут перезаписаны записями из журнала лидеров.

---

Чтобы прокомментировать вашу обработку ситуации.

1, если узел s1 получает отклонение от s3 и обнаружил, что журнал s3 является более новым, чем он сам, и не устанавливает себя в качестве лидера, даже если он получает большинство голосов

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

В последнем абзаце §5.3 говорится о том, как этот простой, основанный на тайм-ауте процесс выбора использовался вместо ранжирования узлов и выбора лучших. Я согласен с результатом. Простые протоколы более надежны.

2. Что касается других узлов, они запоминают информацию лидера, за которую проголосовали, если приходит новый запрос на голосование (с большим <lastTerm, lastIndex>), они голосуют за узел с большим <lastTerm, lastIndex>,

Это строго запрещено, потому что это разрушает выборы лидера. То есть, если у вас это есть, вы очень часто будете выбирать нескольких лидеров. Это плохо. Я не могу не подчеркнуть, насколько это плохо. Плохо, плохо, плохо.