Блог

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

Или для линеаризуемости Raft для чтения требуется кворум для чтения?

Ну, линеаризуемость относится как к чтению, так и к записи, и да, оба выполняются с кворумом. Чтобы сделать чтение линеаризуемым, чтение должно обрабатываться лидером, и лидер должен убедиться, что он не был заменен новым лидером после применения чтения к конечному автомату, но перед ответом клиенту. На практике, однако, многие реальные реализации используют упрощенные модели согласованности для чтения, например, разрешающие чтение от подписчиков. Но обратите внимание, что, хотя кворумы гарантируют линеаризуемость для кластера Raft, это не означает, что запросы клиентов линеаризуемы. Чтобы расширить линеаризуемость для клиентов, необходимо добавить сеансы, чтобы не допустить, чтобы удаленные / дублированные клиентские запросы создавали несколько коммитов в журнале Raft для одного коммита, что нарушило бы линеаризуемость.

кууджо объяснил, что такое линеаризуемость. Я отвечу на другие ваши сомнения в вопросе.

But there may be a portion of the participants that don't have the latest logs or that they have the logs but haven't received instructions to commit those logs .

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

• Даже если лидер зафиксировал запись в журнале (скажем, LogEntry с индексом = 8) и ответил клиенту, фоновые процедуры все еще пытаются синхронизироваться logEntry:8 с другими одноранговыми узлами. Если RPC завершается с ошибкой (это возможно)
• Raft периодически отправляет сердцебиение (своего рода AppendEntries), это сердцебиение RPC синхронизирует журналы, которые есть у лидера, с подписчиками, если у подписчиков его нет. После того, как подписчики получат logEntry:8 , подписчики будут сравнивать его локальный commitIndex и leaderCommitIndex в аргументах RPC, чтобы решить, следует ли ему совершать logEntry:8 . Если лидер выходит из строя сразу после фиксации журнала (это редко, но возможно)
• Основываясь на правиле выборов, только тот, у кого есть logEntry:8 , может выиграть выборы. После избрания нового лидера новый лидер продолжит использовать сердцебиение для синхронизации logEntry:8 с другими одноранговыми узлами. Что произойдет, если последователь отстает настолько, что не может получить все журналы от лидера? (это часто случается, когда вы пытаетесь добавить новый узел). В этом сценарии Raft будет использовать механизм RPC моментального снимка для синхронизации всех данных и обрезанных журналов.