Что происходит с незафиксированными предыдущими записями в журнале терминов в алгоритме Raft?

#consensus #raft

#консенсус #raft

Вопрос:

Здесь есть ряд вопросов по StackOverflow вокруг рисунка 8, обсуждаемых в разделе 5.4.2 в оригинальной статье Raft:

Рисунок 8

Что не было разъяснено в документе и ни в одном из ответов, так это точная судьба этой проблемной записи (2, 3) . Мой вопрос двоякий:

  1. Что именно происходит с записью с индексом 2 во время срока 3 (2, 3) , сделанной S5? На рисунке упоминается, что S5 не станет лидером, потому что большинство отклонит его RequestVotes. Означает ли это, что после получения RPC AppendEntries S5 затем перезапишет свою запись (2, 3) с помощью (2, 2) и (3, 4) согласно текущему лидеру в (e)?
  2. Если S5 вынужден перезаписать эту запись, и она никогда не фиксируется, какой ответ должен получить отправивший (1, 3) клиент? Получают ли клиенты подтверждения для незафиксированных записей, как если бы они уже были применены к конечному автомату?

Ответ №1:

На рисунке упоминается, что S5 не станет лидером, потому что большинство отклонит его RequestVotes

Как и в (e) в документе raft, S5 не станет лидером, потому что журналы S5, по крайней мере, не соответствуют журналам большинства (S1, S2, S3)

Означает ли это, что после получения RPC AppendEntries S5 затем перезапишет свою запись (2, 3) на (2, 2) и (3, 4) в соответствии с текущим лидером в (e)?

Да, журналы S5 будут перезаписаны журналами текущего лидера. Цитируется из статьи raft:

Если журнал подписчика не соответствует журналу лидера, проверка согласованности AppendEntries завершится ошибкой в следующем RPC AppendEntries. После отклонения лидер уменьшает nextIndex и повторяет RPC AppendEntries. В конечном итоге nextIndex достигнет точки, в которой совпадают журналы лидера и последователя. Когда это произойдет, AppendEntries завершится успешно, что удалит все конфликтующие записи в журнале подписчика и добавит записи из журнала лидера (если таковые имеются).

Получают ли клиенты подтверждения для незафиксированных записей, как если бы они уже были применены к конечному автомату?

Нет, клиенты получают подтверждения за зафиксированные записи только тогда, когда запись была безопасно реплицирована. Пожалуйста, посмотрите цитату из статьи raft:

Когда запись была безопасно реплицирована (как описано ниже), лидер применяет запись к своему конечному автомату и возвращает результат этого выполнения клиенту.

Существует также случай, когда лидер скопировал запись в журнале, но вылетает до ответа клиенту или ответ теряется при отправке по сети, клиенту необходимо повторить попытку, в результате чего команда выполняется несколько раз. Цитируется из статьи raft:

Однако, как описано до сих пор, Raft может выполнять команду несколько раз: например, если лидер завершает работу после фиксации записи в журнале, но до ответа клиенту, клиент повторит команду с новым лидером, что приведет к ее выполнению во второй раз. Решение заключается в том, чтобы клиенты присваивали уникальные серийные номера каждой команде. Затем конечный автомат отслеживает последний серийный номер, обработанный для каждого клиента, вместе с соответствующим ответом. Если он получает команду, серийный номер которой уже был выполнен, он немедленно отвечает без повторного выполнения запроса

Комментарии:

1. Спасибо за это подробное объяснение!