Когда последователь Raft должен записывать RPC?

Я изучаю Raft из расширенной версии paper. В разделе 5.2 (Выборы лидера) газеты говорится:

Если последователь не получает сообщения в течение периода времени, называемого тайм-аутом выборов, то он предполагает, что жизнеспособного лидера нет, и начинает выборы, чтобы выбрать нового лидера.

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

Мой вопрос: когда подписчик должен распознать RPC как действительное сообщение и записать его, чтобы предотвратить истечение времени ожидания?

Редактировать:

Моя текущая реализация выглядит следующим образом:

  • RequestVote сбрасывает тайм-аут только тогда, когда сервер дает голос
  • AppendEntries сбрасывает тайм-аут, если его срок не меньше, чем у сервера

В большинстве случаев это работает нормально, но иногда приводит к долгим выборам. Рассмотрим кластер Raft с 2 серверами, оба подчиненных. Сервер №1 имеет более свежий журнал, но сервер №2 имеет более крупный срок.

В этой настройке сервер №1 должен постоянно запускать 2 выбора, чтобы стать лидером, что (интуитивно) происходит с вероятностью <50%. Если сервер №2 начинает выборы и тайм-ауты, его срок увеличивается, и следующие выборы сервером №1 снова не удастся. На практике это может привести к тому, что все выборы будут длиться несколько секунд, даже если серверов всего несколько. Интересно, есть ли какие-то подходы к решению этой проблемы (или это на самом деле не проблема).


distributed-system raft consensus
person Jian Gao    schedule 04.04.2021    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Узел Raft, выполняющий роль Последователя, отвечает на два типа запросов:

  • Добавление записей от лидера
  • Запросить голос от кандидата

Если последователь получает AppendEntries от текущего лидера, он должен выполнить все проверки (т. Е. Термин из запроса, сопоставление журнала), и если все проверки выполнены, последователь должен добавить полученные записи из запроса. Последователь также должен сбросить тайм-аут выборов при получении AppendEntries от текущего лидера, потому что AppendEntries также служит контрольным сигналом (лидеры также отправляют периодические запросы AppendEntries без журналов, чтобы предотвратить истечение времени ожидания у Follower и начало новых выборов).

Если Последователь получает RPC RequestVote, и если Последователь решает предоставить свой голос этому Кандидату, Последователь также сбросит тайм-аут своего выбора.

person msantl    schedule 05.04.2021
comment
Спасибо за ответ. Это очень похоже на мою реализацию, но я все еще не понимаю некоторых моментов. Во-первых, следует ли сбрасывать тайм-аут, если мы отклоняем AppendEntries только потому, что предыдущая запись в журнале не совпадает. Во-вторых, я думаю, что иногда такая реализация может привести к долгому процессу выборов (см. Мою редакцию). - person Jian Gao; 06.04.2021
comment
Хорошая мысль, мой ответ не совсем ясен. Последователь должен сбросить тайм-аут выбора для AppendEntries от текущего лидера, прежде чем проверять свойство сопоставления журнала, потому что последователь отклонит этот RPC AppendEntries, а лидер будет использовать это отклонение для уменьшения значения nextIndex, чтобы обработать несоответствия, заставляя последователей журналы, чтобы продублировать свои собственные. Я отредактировал ответ, чтобы прояснить это. - person msantl; 06.04.2021
comment
В документе Raft в разделе 5.6 «Сроки и доступность» описывается реализация тайм-аута выборов и способы уменьшения фазы выборов лидера, выбирая тайм-ауты случайным образом из фиксированного интервала (например, 150–300 мс). Вы можете попробовать оптимизировать настройку, указав интервал времени ожидания выборов. В идеале у вас никогда не будет кластера Raft из 2 узлов, чтобы кластер сходился быстрее. - person msantl; 06.04.2021