Что происходит с незафиксированными предыдущими записями журнала терминов в алгоритме 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)? Получают ли клиенты подтверждения для незафиксированных записей, как если бы они уже были применены к конечному автомату?

raft consensus
person eliquinox    schedule 01.09.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

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

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

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

person Khanh TO    schedule 02.09.2020
comment
Спасибо за подробное объяснение! - person eliquinox; 03.09.2020