Когда лидер ACKs клиент в DistributedLog?

Question

Я с трудом понимаю, когда лидер на самом деле ACKs клиент. Вот часть документации DistributedLog:

Каждой пакетной записи, добавленной к сегменту журнала, назначается монотонно увеличивающийся идентификатор записи автором сегмента журнала. Все записи пишутся асинхронно в конвейере. Таким образом, средство записи сегмента журнала обновляет указатель в памяти, называемый LAP (LastAddPush), который является идентификатором записи последней пакетной записи, помещенной записывающим устройством в хранилище сегмента журнала. Записи могут быть записаны не по порядку, но подтверждены только в порядке идентификатора записи. Наряду с успешными квитанциями средство записи сегмента журнала также обновляет указатель в памяти, называемый LAC (LastAddConfirmed). LAC - это идентификатор последней записи, уже подтвержденной автором. Все записи, записанные между LAC и LAP, являются неподтвержденными данными, которые они не видны читателям.

Читатели могут читать записи вплоть до LAC, так как известно, что эти записи надежно реплицируются - таким образом, их можно безопасно читать без риска нарушения порядка чтения. Автор включает текущий LAC в каждую запись, которую он отправляет в BookKeeper. Поэтому каждая последующая запись делает записи в предыдущей записи видимыми для читателей. Обновления LAC могут быть добавлены в следующую запись, написанную автором. Поскольку читатели являются строго последователями, они могут использовать LAC для чтения надежных данных из любой реплики без необходимости какого-либо общения или координации с автором.

DL вводит один тип системной записи, которая называется контрольной записью - она ​​действует как запрос на фиксацию в алгоритме двухфазной фиксации. Если никакие записи приложения не поступают в указанный SLA, средство записи сгенерирует контрольную запись. С записью контрольной записи это продвинет LAC потока журнала. Контрольная запись добавляется либо сразу после получения подтверждений от записи пользовательской записи, либо периодически, если записи приложения не добавляются. Это настроено как часть политики очистки писателя. Хотя записи контрольного журнала присутствуют в потоке физического журнала, они не доставляются программами чтения журнала в приложение.

Теперь рассмотрим следующий сценарий:

1. Лидер публикует сообщение для бухгалтера
2. Подписчики получают сообщения, добавляются в журнал и отправляют ACK руководителю.
3. Лидер получает подтверждение от последователей, увеличивает LAC и отвечает клиенту, что сообщения подтверждены.
4. ТЕПЕРЬ: Лидер терпит неудачу прежде, чем он сможет соединиться с последователями, что LAC был увеличен.
5. Вопрос заключается в следующем: поскольку потенциальный лидер не знает о том факте, что LAC был увеличен, он становится новым лидером и усекает журнал до старого LAC, что означает, что мы потеряли запись в журнале, которая была подтверждена предыдущим лидером.

В результате клиент подтвердил, что сообщение было успешно написано, но оно было потеряно.

Answer 1

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

Есть несколько случаев:

1) если лидер изящно закроет журнал, он заклеит сегмент журнала, в который он пишет. LAC будет расширен и будет также записан как часть метаданных сегмента журнала (которые хранятся в хранилище метаданных).

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

• а) Он попытается запечатать последний сегмент журнала, который был написан предыдущим лидером. Процесс печати выполняется клиентом бухгалтера, который состоит из двух частей: (а) он будет ограждать сегмент бревна. Ограждение обеспечивает, что в этом сегменте журнала больше не может происходить запись. (b) затем он выполнит прямое восстановление из последнего известного LAC и восстановит записи, которые были записаны, но еще не зафиксированы.

• б) После восстановления последнего сегмента журнала новый руководитель откроет новый сегмент журнала для записи записей.

Надеюсь, это объясняет ваш вопрос.

DistributedLog также имеет документ, опубликованный в ICDE 2017. Вы можете получить его здесь.