Введение
В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.
Алгоритм Paxos: соглашение с большинством
Paxos – базовый алгоритм консенсуса, гарантирующий достижение единого решения (одного значения) в асинхронной сети при сбоях узлов, если работает хотя бы большинство. Paxos оперирует тремя ролями узлов – предлагающие (proposers), акцепторы (acceptors) и обучающиеся (learners) – которые могут сочетаться на одних и тех же серверах. Предлагающие выдвигают значения, акцепторы голосуют за них, а обучающиеся узнают результат выбора. Ключевое свойство Paxos – безопасность (safety): он гарантирует, что два разных узла не зафиксируют разные решения, даже если сообщения теряются или узлы перезагружаются. Однако прогресс (liveness) возможен только при доступности кворума узлов и при отсутствии бесконечных перегонов лидеров.
Фазы протокола Paxos и Multi-Paxos
Базовый Paxos (иногда называемый Single-Decree Paxos) состоит из двух фаз протокола с обменом сообщениями между предлагающими и акцепторами. Эти фазы зачастую обозначают как Prepare (подготовка) и Accept (принятие):
Фаза 1: Prepare (подготовка). Предлагающий выбирает уникальный номер предложения n выше всех использованных ранее и рассылает запрос Prepare(n) всем акцепторам. Акцептор, получив Prepare с номером больше всех ранее увиденных, отвечает согласием Promise(n) и обещает не принимать предложения с меньшим номером. Он также сообщает предлагающему, какое значение v_a с каким номером n_a он уже принял, если принял.
Фаза 2: Accept (принятие). Получив ответы большинства акцепторов (кворума) на фазе Prepare, предлагающий определяет значение для принятия: обычно это уже предложенное ранее значение с наибольшим номером из ответов, либо собственное новое значение, если акцепторы ещё ничего не приняли. Затем предлагающий рассылает запрос Accept(n, v) с номером n и выбранным значением v. Акцепторы при получении Accept(n, v) проверяют, не принимали ли они обещаний с номером выше n. Если нет – принимают значение, сохраняя n_a = n, v_a = v, и отвечают подтверждением Accepted/ack(n). Когда предлагающий получает подтверждения от большинства акцепторов, значение считается избранным (committed), и предлагающий уведомляет обучающихся о принятом значении.
Paxos требует сохранения состояния акцепторов на стабильном хранении (диск), чтобы узел после сбоя не забыл о данных обещаниях и принятых значениях. Два обещания с разными значениями не могут быть одновременно подтверждены большинством – это обеспечивает единственность решения. При этом, если предложения с большим номером вытесняют предыдущие, алгоритм всё равно сохраняет префиксную целостность: новое значение может принять кворум только если учтены ранее выбранные значения.
Для последовательности решений (например, записи журнала команд) базовый Paxos применяется многократно для разных «номеров слотов» журнала. На практике используется оптимизированный режим Multi-Paxos, при котором после первоначального раунда один узел выполняет роль лидера (координатора) для всех последующих записей, пока не произойдет сбой. Лидер, получив клиентские операции, сам выступает предлагающим для новых значений, и благодаря доверию от акцепторов может пропускать фазу Prepare для каждого значения, сразу рассылая Accept-запросы (то есть решения принимаются быстрее, аналогично непрерывной работе с одним координатором). Так достигается эффективность, близкая к репликации с одним ведущим узлом: сообщения фаз Prepare редки, пока лидер не меняется. Выбор нового лидера в Paxos не выделен в отдельный механизм, как в Raft или Zab – лидер определяется де-факто тем предлагающим, которому удалось протолкнуть своё предложение (обычно с наивысшим номером). Тем не менее Multi-Paxos подразумевает, что система может назначать один узел координатором (например, административно или случайно) и при сбое координатора переходить к новому раунду Paxos с увеличением номера эпохи (номер предложения) для выбора следующего лидера.
Paxos известен своей теоретической строгостью и доказанной корректностью. Он гарантирует консистентность (единство значений) при асинхронной связи и падениях узлов, требуя для прогресса лишь доступности большинства акцепторов. Принято считать, что Paxos предоставляет CP-модель в терминах CAP-теоремы: консистентность и устойчивость к разделению, пожертвуя доступностью, когда кворума нет. Основной недостаток Paxos – сложность понимания и реализации на практик. Из-за сложности многим системам было трудно внедрить Paxos напрямую, что стимулировало разработку более инженерно понятных алгоритмов, таких как Raft.
Обработка сбоев и восстановление в Paxos
Алгоритм Paxos устойчив к отказам части узлов: пока работоспособно хотя бы большинство акцепторов, новое значение может быть выбрано. Если текущий лидер (координатор Multi-Paxos) выходит из строя или теряет связь, другие предлагающие могут инициировать новые раунды Prepare с более высоким номером предложения, что фактически означает выбор нового лидера. За счёт системы кворумов старый и новый лидеры никогда не смогут каждый обеспечить большинство голосов одновременно, поэтому консистентность не нарушается. Paxos допускает длительные остановки (например, если менее половины узлов доступны, прогресс приостанавливается, но ранее достигнутое решение не отменится). После восстановления узлы синхронизируют свои журналы на основе принятых значений: уже принятые (committed) операции будут доставлены от обучающихся или лидера. Протокол требует, чтобы каждый акцептор хранил на диске свой последний обещанный номер n_p и принятый значение v_a с номером n_a. Это гарантирует, что узел, восстановившись, не нарушит ранее данные обещания не голосовать за «старые» предложения. Новый лидер, набрав кворум в Prepare, узнаёт о уже принятом значении (если оно было) и обязан повторно предложить именно его – тем самым обеспечивается, что финальное решение не потеряется даже при смене лидера. Таким образом, Paxos обеспечивает живучесть данных: ни сбои узлов, ни произвольные задержки сообщений (в пределах модели частичного синхронного выполнения) не приводят к противоречиям – система либо продлевает время выбора, либо приостанавливается до восстановления кворума, но не принимает некорректных решений.
Пример псевдокода Paxos
Ниже приведён упрощённый псевдокод работы ключевых ролей Paxos – предлагающего и акцептора – демонстрирующий описанные фазы алгоритма (на основе классического описания):
# Предлагающий (Proposer)
function proposer(value):
# выбирается уникальный номер предложения
choose n > last_proposal_number
send Prepare(n) to all acceptors
if receive Promise(n, n_a, v_a) from majority:
if any acceptor responded with a prior accepted value:
# берем значение с самым новым n_a
v' = value with highest n_a among responses
else:
# берем изначальное значение
v' = value
send Accept(n, v') to all acceptors
if receive Accepted(n) from majority:
# значение v' принято большинством
- сообщить обучающимся
send Decided(v') to learners
# Акцептор (Acceptor) - хранит состояния n_p, n_a, v_a
on receive Prepare(n) from proposer:
# предложение новее всех ранее виденных
if n > n_p:
# запоминаем номер последнего обещания
n_p = n
# сообщаем свое последнее принятое значение (если было)
reply Promise(n, n_a, v_a)
on receive Accept(n, v) from proposer:
# предложение не "устарело"
if n >= n_p:
n_p = n
n_a = n
# принимаем новое значение с номером n
v_a = v
# подтверждаем принятие
reply Accepted(n)
Этот протокол обеспечивает, что акцептор, обещавший не принимать старые номера, не примет значение от старого лидера после того, как увидел более новое предложение. А предлагающий, узнав о ранее принятых значениях (через v_a), повторно предлагает их, чтобы не потерять уже подтверждённое. В итоге достигается единогласие: как только большинство акцепторов примет какое-либо значение, оно становится решением. Paxos доказано корректен и является базой для множества консенсус-протоколов в отрасли.
Алгоритм Raft: консенсус, «понятный» разработчикам
Raft (Diego Ongaro, John Ousterhout, 2013) был создан как более простой для понимания альтернативный консенсус-алгоритм, обеспечивающий те же свойства, что и Paxos. Raft также относится к классу алгоритмов повторяющегося консенсуса для реплицированного журнала (replicated log) – т.е. поддерживает реплицированную машину состояний: все узлы применяют одни и те же команды в одном порядке, благодаря чему состояние на них остаётся согласованным. В отличие от классического Paxos, Raft явно разделяет подзадачи: (1) выбор лидера, (2) репликация логов и (3) смена конфигурации (масштабирование). Основная идея Raft – всегда иметь явно выбранного лидера, через которого проходят все записываемые изменения, что упрощает понимание протокола. Алгоритм Raft гарантирует эквивалентную Paxos отказоустойчивость и консистентность, но проще в реализации и обучении.
В кластере Raft каждый узел может находиться в одном из трёх состояний: Follower (ведомый), Candidate (кандидат) или Leader (лидер). В нормальном режиме имеется один лидер, остальные узлы – ведомые, которые пассивно реплицируют журнал команд от лидера. Если лидер выходит из строя или связь с ним теряется, узлы переходят к выборам нового лидера. Ниже показана схема состояний узла в Raft и переходов между ними при выборах лидера:
Выбор лидера в Raft
Raft добивается согласованного выбора лидера с помощью раундов голосования, называемых термы (term). Термы пронумерованы и хранятся на каждом узле. В начале работы все узлы – Followers и не имеют лидера. Каждый Follower запускает таймер случайной продолжительности (election timeout). Если таймаут истёк, не получив «heartbeat» сообщения от лидера, узел считает, что лидера нет, и сам переходит в состояние Candidate, увеличивает свой терм и начинает выборы нового лидера. Кандидат голосует за себя и рассылает всем остальным узлам запрос RequestVote с указанием своего терма и индекса последней записи в своём журнале. Каждый узел (Follower), получив такой запрос, принимает решение дать голос или отказать, в соответствии с правилами:
Голосующий Follower сравнивает терм кандидата со своим текущим. Если терм кандидата меньше (устарел) – голос отклоняется. Если терм кандидата не меньше, Follower обновляет у себя текущий терм и может проголосовать.
Каждый Follower имеет право голоса только за одного кандидата в рамках одного терма (он запоминает
votedFor= candidateId). Повторные запросы от других кандидатов в том же терме отклоняются.Follower также проверяет «актуальность журнала» кандидата: голосует только если журнал кандидата не отстаёт от его собственного (по индексу и терму последней записи). Это гарантирует, что выбран будет кандидат с наиболее продвинутым журналом, что облегчает последующую синхронизацию логов.
Кандидат, собравший голоса большинства узлов (кворум > N/2), побеждает и становится новым лидером (переходит в состояние Leader). С этого момента он отправляет всем остальным периодические сообщения Heartbeat (пустые AppendEntries RPC) с целью уведомить их о своём лидерстве и предотвратить новые выборы. Если кандидат не набрал большинство (например, голоса разделились между несколькими кандидатами) или получил от лидера сообщение с более высоким термом, выборы завершаются неуспешно: кандидат возвращается в Follower и ждёт нового таймаута, либо признаёт лидером узел с более высоким термом. Использование рандомизированных таймаутов предотвращает ситуации вечной ничьи – обычно один из узлов успеет первым запустить выборы. Выборы в Raft проходят быстро (за время порядка двух таймаутов) и гарантируют, что в каждый момент не появится два лидера в одном терме (благодаря голосованию по большинству и правилу одного голоса). Каждый новый терм отмечается в логах; записи предыдущих термов могут быть не завершены, но Raft гарантирует, что они не повлияют на консистентность.
Репликация журнала и коммит записи
Как только выбран лидер, все клиентские запросы на изменение состояния проходят через него. Лидер принимает, например, команду «записать значение X», добавляет соответствующую запись в свой журнал (log) локально и присваивает ей текущий терм и следующий порядковый индекс. Далее лидер рассылает RPC AppendEntries своим фолловерам с новыми записями. В запрос AppendEntries лидер указывает предыдущий индекс и терм для контроля целостности последовательности. Каждый Follower, получив такой запрос, проверяет: если у него в журнале нет записи с указанным предыдущим индексом и термом (т.е. локальный журнал отстаёт или содержит конфликтующее окончание), то Follower отказывает в AppendEntries и может запросить у лидера пропущенные записи или убрать «лишние» локальные записи. Этот механизм, вместе с проверкой актуальности журнала при голосовании, обеспечивает сходимость журналов: рано или поздно журналы всех узлов станут префиксно-одинаковыми последовательностями команд.
После того как запись успешно записана на большинстве узлов (лидер получил подтверждения AppendEntries от кворума), лидер помечает эту запись как зафиксированную (committed). Зафиксированная запись считается окончательно применённой – лидер может выполнить команду в своей машине состояний и вернуть результат клиенту. Также в каждом AppendEntries лидер передаёт индекс последнего зафиксированного им entry (commitIndex); получив такое сообщение, фолловер тоже помечает у себя соответствующие записи как зафиксированные. Таким образом, команда становится видимой для чтения на всех узлах только после репликации на большинство (это реализует требование линеаризуемости операций). Raft отдает приоритет консистентности над доступностью: если недостаточно узлов для кворума (например, сеть разделилась и у лидера нет связи с большинством), лидер не сможет продвинуть commitIndex – система приостанавливает обработку изменений, сохраняя ранее достигнутую согласованность (CP-модель по CAP). Зато чтения возможно выполнять с лидера (чтобы быть уверенным в самом актуальном состоянии) либо, при определённых условиях, с Followers (если допустима слегка устаревшая информация). В etcd (реализация Raft) чтения по умолчанию линеаризуемые – то есть проходят через лидер или с его заверением консистентности, а «быстрые» неблокирующие чтения с Followers должны явно запрашиваться как несовместимые со строгой консистентностью.
Raft использует более жёсткую модель лидерства, чем Paxos: лидер полностью управляет потоком команд, Followers не участвуют в предложении новых значений. Это упрощает понимание — система сводится к классической репликации ведущий-ведомый, дополненной безопасным переизбранием лидера в случае сбоя. Важное свойство — лог Matching Property Raft: если две записи на разных узлах имеют одинаковый индекс и терм, то гарантировано весь префикс журнала до этого индекса совпадает. Это достигается механизмом отката конфликтующих записей на Followers: если запись на follower не соответствует по терму записи на лидере (означает, что в прошлом она была записана под руководством другого лидера, который не смог довести её до commit), лидер заставит follower удалить эту «осиротевшую» часть журнала и заменить записями из своего журнала. Тем самым консистентность логов восстанавливается.
Обработка сбоев и восстановление в Raft
Raft спроектирован так, чтобы сохранять безопасность (не противоречить уже зафиксированным записям) даже при произвольных отключениях узлов, сетевых задержках или разделениях. Отказоустойчивость достигается, пока работоспособно большинство узлов: это минимально необходимое условие для любого алгоритма консенсуса в модели с отказами (иначе нет кворума). При падении лидера обнаружение происходит через таймаут Followers – как описано, они инициируют выборы нового лидера. Важная деталь: каждый узел хранит на диске currentTerm и votedFor, а также весь свой журнал. Это означает, что узел, перезагрузившись, не «забывает» о том, кому он отдал голос в данном терме, а также не теряет записанные записи журнала. Протокол Raft запрещает лидеру в терме T считать запись commit’нутой, пока она не записана на большинстве узлов в терме T. Эта гарантия, наряду с правилом актуальности журнала при голосовании, обеспечивает, что новый лидер всегда будет иметь все записи, зафиксированные предыдущим лидером. Благодаря этому, новый лидер продолжит с корректного состояния.
В случае, если узел отстал (например, долго был недоступен), механизм догонки журнала позволяет ему нагнать текущее состояние. Лидер в сообщениях AppendEntries указывает prevLogIndex/prevLogTerm для проверки, и если у отставшего follower обнаружится рассинхрон, он получит отказ AppendEntries. Лидер будет понижать prevLogIndex (или пересылать snapshot) до тех пор, пока follower не синхронизируется. В крайних случаях применяется передача snapshot – компактного снимка состояния – если отставание очень велико. Snapshot включает все команды до определённого индекса, и follower просто заменяет своё состояние снимком и журнал начиная с этого индекса.
Raft существенно упрощает периодическое обслуживание системы. Он включает встроенный механизм сжатия журнала (log compaction): лидер время от времени сохраняет snapshot состояния (например, на диск) и может отбросить старые записи журнала, которые включены в snapshot. Это предотвращает неограниченный рост журнала и ускоряет восстановление узлов с нуля (им достаточно получить актуальный снапшот и последние записи). Также Raft определяет процедуру безопасного изменения состава кластера (например, добавление/удаление узлов) через перекрывающиеся кворумы, чтобы не нарушать консенсус – сначала вводится временная конфигурация с увеличенным кворумом, затем старая удаляется, что обеспечивает наличия пересечения большинства на протяжении изменения.
В результате, Raft предоставляет разработчикам относительно простую модель: единственный лидер, реплицирующий команды на Followers. Он гарантирует линейризуемость операций (при чтении с лидера) и высокую доступность при сбое до N/2 узлов. Реализации Raft, такие как etcd, показали высокую производительность – порядка десятков тысяч операций в секунду на кластер – и широко внедрены в современных системах. Благодаря фокусировке на понятности, Raft стал популярным выбором для новых проектов, требующих консенсуса.
Пример реализации Raft (фрагмент кода)
Ниже приведён упрощённый пример обработки RPC запроса голосования (RequestVote) на языке Python, иллюстрирующий логику выбора лидера в Raft. Каждый узел хранит current_term, идентификатор voted_for (кому отдал голос в текущем терме или None), а также индекс и терм последней записи журнала (last_log_index, last_log_term):
class RaftNode:
def __init__(
self
) -> None:
self.current_term = 0
self.voted_for = None
self.last_log_index = 0
self.last_log_term = 0
# ... (журнал и другие состояния)
def on_request_vote(
self,
term, candidate_id,
last_log_index,
last_log_term,
) -> bool:
# Если у кандидата устаревший терм, отказать
if term < self.current_term:
return False
# Если не голосовали в этом терме
# или уже голосовали за этого кандидата...
if (
self.voted_for is None
or self.voted_for == candidate_id
):
# ...и лог кандидата не отстает (последняя запись не старее нашей)
if last_log_term > self.last_log_term or \
(last_log_term == self.last_log_term
and last_log_index >= self.last_log_index):
# Обновить свой термин и отдать голос
self.current_term = term
self.voted_for = candidate_id
return True
return False
Этот код реализует правила голосования: узел отдаст голос кандидату, если (a) кандидат не в старом терме, (b) узел ещё не голосовал в этом терме, и (c) журнал кандидата актуален. Подобная логика встроена в реализации etcd/Consul (написанных на Go) и обеспечивает корректность выборов. После избрания лидера, начинается репликация логов с помощью RPC AppendEntries (в коде она бы была реализована в другом методе, проверяющем согласованность индексов и терминов). Полный алгоритм Raft включает ещё детали (heartbeat, отработка отказов AppendEntries, установка commitIndex, снапшоты), но показанный фрагмент демонстрирует суть выбора лидера.
Алгоритм ZAB: атомарная широковещательная рассылка в ZooKeeper
Zab (ZooKeeper Atomic Broadcast) – протокол консенсуса, разработанный специально для системы Apache ZooKeeper. По замыслу, Zab обеспечивает атомарную (неделимую) широковещательную рассылку сообщений с тотальным порядком и устойчивостью к отказам. Это означает, что все узлы ZooKeeper применяют все транзакции (изменения состояния) в одном и том же порядке – в итоге их состояния идентичны. Zab близок по целям к Paxos, но спроектирован как более узкоспециализированный протокол мастер-репликации (primary-backup) с упором на простоту реализации в реальном продукте. Он использует модель с одним лидером (primary) и набором последователей (followers), аналогично Raft. Основные этапы работы Zab: (1) выбор лидера (Leader Election), (2) синхронизация состояния лидера с последователями (Discovery, или фазу восстановления) и (3) атомарная рассылка сообщений (Broadcast). Пока кластер имеет лидера и кворум живых узлов, все клиентские операции последовательно проходят через лидера и распространяются на последователей.
Выбор лидера и синхронизация состояния (Discovery)
Процесс запуска или восстановления кластера ZK начинается с выборов лидера. ZooKeeper включает реализацию протокола выбора лидера (например, алгоритм FastLeaderElection). Важное условие: выбирается тот узел-лидер, который обладает самым новым состоянием (наибольший номер транзакции zxid) среди кворума узлов. Это похоже на принцип Raft о наиболее актуальном логе. После выбора один узел становится лидером, остальные – его последователями. Но лидер не начинает сразу принимать новые операции – сначала проходит фаза leader activation, или discovery: лидер должен убедиться, что большинство (кворум) последователей синхронизировали с ним состояние. Для этого лидер устанавливает соединения с каждым последователем. Каждый узел хранит последний zxid (уникальный идентификатор записи ZK, включающий номер эпохи лидера и счетчик). Лидер запрашивает у каждого последователя его zxid и сверяет со своим журналом транзакций:
Если у последователя не хватает каких-то транзакций, лидер посылает ему недостающие записи журнала, чтобы подтянуть его до своей последней транзакции.
Если у последователя есть «лишние» записи (с более высокими zxid, что может быть результатом работы предыдущего лидера, не успевшего подтвердить эти записи), то лидер указывает последователю откатить (отбросить) эти несогласованные изменения. Это необходимо, так как раз они не были зафиксированы большинством ранее, то они не должны влиять на состояние системы после восстановления.
Когда лидер и последователь достигли одинакового последнего zxid (т.е. последователь синхронизировался), лидер включает этого последователя в кворум подтверждённых. Лидер считается полностью активированным, когда заручился поддержкой кворума (большинства) узлов в актуальном состоянии. Этот процесс гарантирует, что только один лидер контролирует систему, и все его последователи начинают с идентичного префикса истории. После этого лидер формально объявляет о начале новой эпохи (epoch) – рассылает специальное сообщение NEW_LEADER и переходит к следующей фазе.
Атомарная широковещательная рассылка (Broadcast)
На фазе broadcast текущий лидер принимает клиентские запросы (транзакции, например изменения узлов ZK) и распределяет их всем последователям. Каждый новый запрос получает уникальный увеличивающийся zxid (состоящий из номера эпохи лидера и счетчика). Лидер посылает предложение (proposal) с этим zxid всем followers (по сути, запись транзакции). Последователи, получив предложение, записывают его в свой лог и отправляют лидеру подтверждение (ACK). Когда лидер собирает ACK от кворума узлов, он отправляет всем узлам команду коммита (commit) для данного zxid – тем самым транзакция считается применённой на всех. Это очень похоже на схему «журнал с главным узлом» и эквивалентно фазе Accept/Commit в Paxos. В ZooKeeper все изменения проходят через такое согласование, что обеспечивает линейный порядок: если одна транзакция A была отправлена раньше B и подтверждена, то все узлы применят A перед B. Заботится об этом лидер, упорядочивая исходящие предложения, а общая очередь подтверждения поддерживается требованием кворума.
Важно подчеркнуть свойства консистентности Zab: он гарантирует надежную доставку (каждая подтверждённая лидером транзакция дойдёт до всех корректных узлов) и тотальный порядок доставки. Кроме того, соблюдается каузальный порядок: если транзакция B отправлена после доставки A на том же узле-инициаторе, то B будет упорядочена после A. Эти гарантии соответствуют семантике ZooKeeper: все узлы видят изменения в одном порядке, а клиент, последовательно отправляющий запросы, видит их в порядке отправки.
Отказоустойчивость и восстановление в Zab
Zab, как и другие консенсус-алгоритмы, рассчитан на работу при падении части узлов. Для прогресса операций требуется доступность кворума (большинства) узлов – обычно N/2 + 1 из N. Если лидер падает, алгоритм запускает процедуру восстановления: оставшиеся узлы прекращают принимать новые транзакции и инициируют новый раунд выбора лидера (новая эпоха). Благодаря фазе синхронизации (discovery), новый лидер сначала приводит кластер в согласованное состояние: догружает отставших, отбрасывает конфликтующие операции. Таким образом, даже если предыдущий лидер погиб посреди передачи транзакции, эта транзакция либо будет восстановлена (если успела попасть к большинству узлов), либо отброшена (если не набрала кворум). С монотонно возрастающими номерами эпох (epoch) у zxid, каждый новый лидер работает в новой эпохе и не конфликтует с событиями прошлых эпох. Это аналогично номерам терма в Raft или номерам раундов в Paxos. Когда завершается очередной цикл выборов и синхронизации, система продолжает приём запросов в обычном режиме (broadcast) с новым лидером.
Протокол Zab был разработан с учётом практических ограничений. Он допускает небольшие оптимизации на уровне реализации – например, последовательная запись транзакции на диск у лидера перед рассылкой предложения, пакетация батчей сообщений и пр. ZooKeeper, используя Zab, достигает высокой производительности: сервис способен обрабатывать тысячи транзакций в секунду на кластер. При этом сохраняется простота: реализация Zab более доступна инженерам, нежели универсальный Paxos. Недостатком Zab можно назвать то, что он привязан к модели «один лидер – многие реплики» и не так универсален: вне контекста подобных координационных сервисов он используется редко. Тем не менее, для класса задач, связанных с распределённым координатором (конфигурация, название лидер, распределённые очереди, блокировки), Zab отлично подходит и применён на практике в ZooKeeper – ключевом компоненте многих систем.
Области применения Paxos, Raft, Zab в реальных системах
Алгоритмы консенсуса нашли применение во множестве распределённых систем, где требуется надёжное хранилище конфигурации, координатор или согласованная репликация данных. Рассмотрим несколько примеров:
Paxos в сервисах Google и распределённых базах данных. Paxos стал основой для ряда внутренних систем Google. В частности, глобально распределённая база данных Google Spanner применяет модификацию Paxos для синхронной репликации данных между датацентрами. Каждый фрагмент данных (split) в Spanner хранится с несколькими репликами; один из узлов выбирается лидером на основе Paxos, и все транзакции проходят через него, чтобы обеспечить внешнюю согласованность (external consistency) данных по всему миру. При сбое лидера Paxos выбирает нового, обеспечивая непрерывную доступность сервиса. Ещё один известный пример – Chubby, распределённый сервис блокировок от Google, также реализует консенсус на основе Paxos. Chubby хранит небольшие, но критически важные данные конфигурации (например, координаты мастер-узлов) и использует Paxos для высокой доступности: даже при сбое узлов, остаётся консистентное хранилище для клиентов. В академических и промышленных реализациях Paxos применяется в репликации метаданных файловых систем (например, в прототипах GFS/HDFS, как отмечается в литературе) и в отдельных компонентах кластеров (мониторинг-кворумы). Например, распределённая файловая система Ceph использует Paxos в сервисе мониторинга (Ceph Monitors) для согласования карты кластера – чтобы все узлы имели единую информацию о состояниях хранилищ и пульсов. Несмотря на существование более простых алгоритмов, Paxos остаётся «золотым стандартом» для сценариев, требующих максимальной надёжности и формально доказанной корректности.
Raft в системах оркестрации, сервис-дискавери и новых СУБД. Благодаря упрощённой реализации, Raft быстро стал популярным в open-source проектах. Яркий пример – etcd, распределённое ключ-значение хранилище, написанное на Go, использующее Raft для репликации данных между узлами. Etcd обеспечивает хранение конфигурации с высокой консистентностью и отказоустойчивостью; он применяется как центральное хранилище состояния в Kubernetes (где сохраняется информация о кластере, сервисах, конфигурациях). При каждом изменении (например, развертывание нового контейнера) запись фиксируется через Raft в etcd, что гарантирует согласованное видение состояния всеми компонентами Kubernetes. Аналогично, HashiCorp Consul – сервис-дискавери и распределённое хранилище настроек – реализует протокол Raft для согласованного хранения данных о сервисах, ключах конфигурации, сессиях и блокировках. Consul отличается тем, что использует gossip-протокол для обнаружения узлов и распространения менее критичных данных (например, здоровья сервисов), но все важные обновления проходят через лидера Consul и фиксируются в журнале Raft. В области баз данных несколько современных распределённых СУБД выбрали Raft как основу консенсуса: например, CockroachDB и YugabyteDB (NewSQL решения) используют встроенный Raft для репликации таблиц между узлами, обеспечивая линеаризуемые транзакции и автоматическое переключение лидера при сбоях. В схожем духе, хранилище TiKV (часть платформы TiDB) применяет Raft для репликации ключ-значений и даже вынесло реализацию Raft как отдельную библиотеку (raft-rs на Rust). Raft сейчас лежит в основе множества cloud-native систем – от систем оркестрации контейнеров до распределённых транзакционных баз – благодаря сочетанию простоты, эффективности и предсказуемости поведения. В реальном окружении Raft-кластеры (3–5 узлов) обычно выдерживают отключение 1–2 узлов без потери консистентности, а производительность их достаточна для тысяч обновлений в секунду при задержках порядка нескольких миллисекунд.
Zab (ZooKeeper) в системах координации и очередях задач. Apache ZooKeeper – пожалуй, самый известный проект, использующий Zab. Zookeeper предоставляет разработчикам примитивы для координации распределённых приложений: сервис обнаружения, конфигурационные узлы, распределённые блокировки, выбор мастера и т.д. Все эти функции требуют согласованности, которую обеспечивает Zab-протокол под капотом ZooKeeper. Исторически ZooKeeper широко применяется в экосистеме Hadoop и Apache: он служит координатором для Apache Kafka (до версии 2.x) – хранит сведения о брокерах, разделах топиков и контролирует выбор контроллера кластера Kafka. Пока Kafka зависел от ZooKeeper, гарантировалось, что, например, только один брокер является лидером конкретного раздела (partition) и что информация о отставании потребителей, балансе и конфигурации – согласованна по всему кластеру. В настоящее время Kafka разрабатывает собственный встроенный консенсус (KRaft, по сути Raft-алгоритм) в рамках KIP-500, чтобы убрать зависимость от ZK, но во многих установках ZK всё ещё является неотъемлемой частью Kafka-кластера. Другой пример – Hadoop HDFS NameNode Federation: ZK используется для выбора активного NameNode в паре (Active/Standby) и согласованного хранения метаданных при failover. В HBase (NoSQL база на Hadoop) ZooKeeper хранит информацию о ведущих регион-серверах. В облачных платформах ZK находит применение как надежный стор для сервис-дискавери (хотя постепенно уступает место более легковесным etcd/Consul). Благодаря Zab, ZooKeeper обеспечивает строгую консистентность данных конфигурации: изменения (создание узла, обновление значения) видны всем клиентам в одном порядке. Особенность ZK – иерархическая модель данных (ZNodes, подобные файловой системе) с поддержкой ephemeral-узлов и наблюдателей (watchers) для отслеживания изменений. Это делает его очень удобным для ряда паттернов (например, выбор лидера через создание узла и наблюдение за ним – classic recipe). Совокупность этих возможностей, опирающихся на консенсус Zab, привела к тому, что ZooKeeper долгое время был де-факто стандартом для координации распределённых систем.
Paxos, Raft и Zab – не просто теоретические протоколы, а фундаментальные технологии, встроенные во множество инфраструктурных проектов. Paxos исторически царил в научной литературе и в системах, требующих предельной надёжности (Google, Amazon). Raft завоевал популярность в open-source сообществе как практически реализуемое решение консенсуса – его следы видно от etcd/Consul до современных NewSQL баз. Zab, хотя и менее универсален, идеально подошёл под нишу координатора сервисов, будучи сердцем ZooKeeper и обеспечивая работу экосистемы Hadoop/Kafka. Каждый из протоколов преследует одну цель – единство состояния при сбоях – но делает это несколько по-своему, что отражается в существующих готовых продуктах.
Обзор готовых решений на базе консенсуса (etcd, ZooKeeper, Consul и др.)
Рассмотрим популярные открытые реализации и продукты, использующие описанные алгоритмы, и сравним их по ключевым характеристикам. К таким решениям относятся etcd (CoreOS/Cloud Native Computing Foundation), Apache ZooKeeper, HashiCorp Consul, а также аналогичные системы координации/регистры сервисов. Ниже приведены краткие обзоры этих проектов и их свойства.
etcd (Cloud Native Computing Foundation)
etcd – это распределённое надежное хранилище ключ-значение, написанное на Go. Оно специально разработано для хранения самой критичной конфигурационной информации в кластерах (например, сведения о расположении сервисов, настройках, блокировках), требующей высокой консистентности. Etcd изначально создан в CoreOS и сейчас развивается под эгидой CNCF. В основе etcd лежит алгоритм Raft – каждый экземпляр etcd-сервера участвует в Raft-кворуме, поддерживая реплицированный лог изменений. Данные etcd организованы как иерархическое пространство ключей (похоже на файловую систему), к ним можно обращаться через gRPC/HTTP API. Etcd обеспечивает линаризуемые чтения и записи по умолчанию, то есть клиент всегда видит самые свежие данные после успешной записи на лидере. Для чтений при необходимости допускается режим последовательной консистентности (менее строгий, позволяющий читать с follower). Etcd ориентирован на быстродействие: в тестах демонстрирует ~10 000 записей в секунду на узел при минимальных задержках. Репликация происходит синхронно на большинство узлов, что классифицирует etcd как CP-систему (Consistent & Partition-tolerant). Типичная конфигурация – 3 или 5 узлов, что позволяет выдерживать отказ 1 или 2 узлов соответственно. Отказоустойчивость etcd определяется свойствами Raft: при падении лидера автоматически выбирается новый, лог догоняется за счёт встроенных механизмов (snapshot, WAL). Разработчики etcd уделяют большое внимание проверке корректности – проект проходит жесткие тесты на устойчивость к сетевым сбоям, задержкам и пр. Etcd широко используется: помимо Kubernetes, его применяют в Cloud Foundry, OpenStack, распределённых системах хранения и др., где требуется надёжный координатор. Особенности etcd: простая установка (один бинарник), удобный API с поддержкой watch-подписок на изменения, возможность квот и авторизации, а также хорошая интеграция с экосистемой Kubernetes. В etcd нет встроенной многодатацентровой репликации – кластер обычно располагается в пределах близко расположенных узлов (для минимизации задержек Raft). Для гео-репликации делают несколько кластеров etcd с поверхностной синхронизацией или используют другие механизмы.
Apache ZooKeeper
ZooKeeper – старейшее решение в этой категории, появившееся как часть Hadoop-экосистемы. Оно представляет собой сервис координации для распределённых приложений, предлагающий абстракцию деревьев znodes (узлов данных), на которых можно осуществлять простые операции (создать, получить, установить данные, удалить) с разными режимами (ephemeral, последовательные узлы). ZooKeeper написан на Java и требует запуска кластера JVM-процессов (обычно 3 или 5 узлов). Для обеспечения консистентности ZooKeeper использует собственный протокол Zab (описанный выше) – фактически, внутри ZK работает постоянно избранный лидер, который обрабатывает все запросы записи, рассылка изменений идёт с помощью атомарной рассылки, требующей подтверждения от большинства узлов. ZooKeeper гарантирует строгую согласованность: все клиенты видят изменения в одном порядке, все успешные записи попадут в логи большинства узлов (и сохранятся на диске на каждом из них). По CAP ZK тоже относится к классу CP. При сетевом разделении меньшинство узлов блокируется для операций (только чтение старых данных), и только на стороне большинства продолжится обработка запросов. Чтения в ZooKeeper могут обслуживаться любым сервером, но по умолчанию клиентская библиотека обеспечивает последовательную консистентность для своего контекста. Чтобы гарантировать чтение свежих данных, клиент может выполнить специальную синхронизацию (опция sync), иначе есть небольшая вероятность прочитать «устаревшее» значение с follower. На практике это редко проблематично для тех задач, где используется ZK (конфигурации, координаторы), потому что требования чаще фокусируются на надёжности записи. Отказоустойчивость: ZK-кластер устойчив к падению менее половины узлов. В случае сбоя лидера остальные по протоколу Zab выберут нового за несколько сотен миллисекунд – на это время сервис приостановит обработку, затем продолжит. Все данные хранятся на диске (с журналированием и снапшотами), поэтому даже полный рестарт кластера с перерывом не теряет состояние. ZooKeeper оптимизирован под большой объем операций чтения и умеренную нагрузку на запись. Он способен обрабатывать тысячи запросов в секунду, масштабируя чтения на всех узлах (т.к. каждый узел может обслуживать запросы на чтение локально, читая свой реплицированный лог). Особенности: модель данных ZK богаче простого KV – древовидное пространство имен с возможностью watch на узлах, что удобно для построения примитивов синхронизации (например, очередей, барьеров, выборов мастера). ZK поддерживает акторы-Observers – узлы без права голоса, которые получают обновления (для географического масштабирования чтений без влияния на кворум). Также есть механизмы quotas, ACL (списки контроля доступа) для безопасности. Многие фреймворки (Hadoop, HBase, Kafka старше 3.0, Solr, Accumulo и др.) полагаются на ZooKeeper для хранения своего состояния или метаданных, благодаря чему ZK прошёл проверку временем. Однако, с развитием более легких систем и переходом на контейнеры, ZK понемногу сдаёт позиции там, где etcd или Consul могут обеспечить сходный функционал проще.
HashiCorp Consul
Consul – система сервис-дискавери и распределённого конфигурирования от компании HashiCorp. Написанная на Go, Consul объединяет в себе несколько ролей: это и реестр сервисов (хранит адреса доступных сервисов, осуществляет их здоровье-check), и Key-Value хранилище для настроек, и база данных для Locks/Sessions (механизм блокировок и лидеров), а также предоставляет базовые возможности сервис-меш (Consul Connect). Для обеспечения консистентного хранения данных Consul применяет алгоритм Raft (через библиотеку HashiCorp Raft), аналогично etcd. Кластер Consul состоит из нескольких серверов (обычно 3 или 5 – они образуют Raft-кворум) и множества агентов-клиентов (запускаются на каждом узле приложения, отвечают за регистрацию сервисов, пробрасывают запросы к серверам). То есть, не все узлы Consul участвуют в консенсусе – большая часть являются клиентами и просто кэшируют данные. Это архитектурное отличие: etcd/ZK требуют участия каждого узла в кворуме, а Consul выделяет роль серверов. Между серверами Consul происходит избирательный обмен: они обмениваются heartbeat и данными Raft, а между всеми узлами (серверами и клиентами) параллельно работает протокол gossip (Serf), который распространяет информацию об участниках, выполняет обнаружение отказов узлов и пр. Consul сочетает сильную консистентность для критичных данных (через Raft) с высокой доступностью для второстепенных (через gossip, допускающий временную рассинхронизацию). Отказоустойчивость: падение лидера Consul инициирует выборы (как в Raft – посредством RequestVote) среди серверов. Падение серверов-кворумов может остановить операции записи (CP), однако механизмы gossip позволяют сохранившимся агентам продолжать локальное обслуживание кэша и health-check’ов, пока кластер не восстановится. Consul отлично поддерживает многодатацентровость: кластеры Consul в разных DC соединяются слабосвязанно (через парные серверы-реплики) и обмениваются лишь регистрацией сервисов, сохраняя независимые кворумы Raft внутри каждого DC. Это позволяет строить глобально распределённый сервис-дискавери, где локальные изменения консистентны (CP), а глобальные могут быть eventual consistent. Производительность: Consul сопоставим с etcd – тысячи операций/сек, небольшие задержки на коммит. Встроенное кэширование на клиентах снижает нагрузку: повторяющиеся чтения не всегда требуют обращения к Raft-кворуму. Простота использования: Consul славится удобным интерфейсом – предоставляет простой HTTP API (включая HTTP-frontend UI для просмотра кластера), имеет встроенные механизмы service health-check (сами агенты отслеживают процессы) и автоматическую регистрацию через конфигурацию или с помощью Orchestration (Nomad, Kubernetes via sync). Настройка Consul несколько сложнее, чем у etcd, из-за необходимости разворачивать агентов на каждом узле и учитывать gossip-трафик. Тем не менее, он предлагает более всеобъемлющее решение "из коробки": и хранение, и обнаружение сервисов, и даже элементарный сервис-меш. Это делает Consul привлекательным для инфраструктур микросервисов, особенно в мульти-облачных и гибридных средах, где нужна балансировка между консистентностью и доступностью.
Другие решения
Кроме упомянутых, существуют и другие системы, применяющие сходные подходы:
Nacos (Alibaba) – платформа конфигурации и сервис-дискавери, популярная в азиатском регионе. Nacos, подобно Consul, поддерживает режимы кластеризации с Raft-консенсусом для хранения данных конфигурации. Он также может работать в режиме без сильного консенсуса (AP) для сервис-дискавери, но при включении persistence полагается на Raft. Nacos интегрирован с экосистемой Spring Cloud в качестве альтернативы Eureka/Consul.
Eureka (Netflix OSS) – реестр сервисов, ориентированный больше на доступность, чем на консистентность. Интересен как контраст: Eureka не использует единый консенсус-алгоритм, полагаясь на репликацию с возможной рассинхронизацией (AP-модель). За счёт этого Eureka продолжит работать даже при разделении, но данные о доступности сервисов могут временно расходиться между узлами. Это приемлемо для сценария клиентского load balancing, но не подходит для хранения важных настроек. Поэтому Eureka не обеспечивает строго консистентного хранилища и не считается напрямую сравнимым с etcd/Consul/ZooKeeper (но часто упоминается вместе как решение для service discovery).
AWS DynamoDB, Cassandra Lightweight Transactions – хотя эти системы в основе ориентированы на eventual consistency (AP), для реализации транзакций или координации обновлений могут использовать внутренние протоколы, вдохновлённые Paxos. Например, в Cassandra есть механизм Lightweight Transactions (CAS-операции), реализованный через алгоритм типа Paxos с четырьмя раундами сообщений, чтобы согласовать вставку только если не было конкурентов. Это частный случай применения консенсуса для согласования на уровне ключа.
Distributed SQL Databases – помимо уже названных CockroachDB и TiDB, отметим Google Cloud SQL (спин-офф Spanner) и Microsoft Cosmos DB – эти сервисы обеспечивают глобальную консистентность по Paxos-/Raft-подобным протоколам. Cosmos DB, например, для уровня с максимальной консистентностью использует протокол Paxos с кворамами для записи в разные регионы.
В целом, практически каждая современная система, требующая надежного лидера или единого источника истины в распределённой среде, строится либо на Paxos, либо на Raft (либо их вариациях). ZooKeeper с Zab был пионером в open-source, но сейчас имеет равнозначные альтернативы. Выбор конкретного решения зачастую диктуется экосистемой и требованиями: Kubernetes-native среды склоняются к etcd, DevOps/VM ориентированные – к Consul, Big Data – к ZooKeeper, облачные платформы – к своим проприетарным Paxos-реализациям.
Сравнительная таблица решений
Ниже приведена таблица, сравнивающая ключевые характеристики etcd, ZooKeeper, Consul и некоторых других решений:
Решение | Алгоритм | Модель консенсуса | Язык реализации | Отказоустойчивость | Производительность | Простота использования |
|---|---|---|---|---|---|---|
etcd | Raft (Leader-based) | CP (строгая консистентность, требует кворума) | Go | 3-5 узлов, терпит сбой до 1-2 узлов; автоматический перевыбор лидера | ~10k+ операций/сек (запись) на кластер; задержка <10 мс на коммит | Очень простой API (gRPC/HTTP); легкий деплой (один бинарник); интеграция с K8s; требуется ручное управление снапшотами для больших данных |
ZooKeeper | Zab (Primary-backup) | CP (строгая сериализация операций) | Java | 3-5 узлов, терпит сбой до 1-2; новый лидер за ~200-500 мс; журнал на диск для сохранности данных | Тысячи оп/сек; чтения масштабируются на followers; задержки 5-10 мс на запись (из-за дискового sync) | Богатый функционал (znodes, watchers); требует JVM, настройка сложнее; клиентские библиотеки для работы; широко проверен в бою |
Consul | Raft + Gossip | CP внутри датацентра (Raft), меж-DC | Go | 3-5 серверов в DC (сбой до 1-2); меж-DC репликация через мосты; автоматическое восстановление, если хотя бы 1 DC жив | ~Thousands op/s (на серверный кластер); чтения часто из кэша клиентов – очень быстрые; сеть gossip добавляет нагрузку | Простое включение сервисов, встроенный health-check и DNS; веб-интерфейс; сложнее etcd из-за архитектуры (нужны серверы + клиенты) |
HashiCorp Vault* | Raft (встроенный) | CP (секреты и токены строго консистентны) | Go | 3-5 узлов (лидер + реплики); перезагрузка лидера с automatic unseal при интеграции с HSM | Ограничен скоростью крипто-операций; ~тыс. запросов/сек | Предназначен для секретов; CLI/UI удобные; требует управления unseal ключами; хорошо документирован |
Nacos* | Raft (для данных) | CP для конфигов; AP для сервис-дискавери | Java | 3 узла в режиме консенсуса; поддерживает cluster mode с различными режими; failover автоматический | Сравнима с ZK/etcd; для Service Discovery – высокая доступность | Интегрирован с Spring Cloud; имеет GUI; но менее известен за пределами Китая |
Eureka* | Нет (AP модель) | AP (eventual consistency, без общего лидера) | Java | Кластер без кворума (каждый узел держит копию); терпит любой сбой кроме полного; требует ручного удаления "зомби" при разделениях | Очень высокая доступность чтения/записи (работает при любых N); но возможны расхождения данных на короткое время | Прост для разработчиков Spring; minimum setup; но не подходит для данных, требующих строгой консистентности |
Примечания: Звёздочкой (*) отмечены решения со специфической областью применения (Vault – хранилище секретов, Nacos/Eureka – сервис-дискавери) для контекста. Они приведены для полноты и показывают варианты компромиссов (например, Eureka жертвует консистентностью ради доступности). Все рассмотренные системы, кроме Eureka, реализуют консенсус с выделенным лидером и требуют большинства узлов для принятия решений. Они обеспечивают схожие гарантии безопасности (никаких «split-brain» при допустимом уровне отказов) и отличаются в основном экосистемой и дополнительным функционалом.
Заключение
Алгоритмы консенсуса Paxos, Raft и Zab решают одну из самых сложных задач распределённых вычислений – достижение единого согласованного состояния при наличии отказов и непредсказуемых задержек. Paxos заложил прочный теоретический фундамент, доказав принципиальную реализуемость консенсуса в асинхронной сети с отказами, но оказался непрост в реализации. Raft упростил практическое внедрение консенсуса, разделив проблему на понятные части и усилив роль лидера, что облегчило понимание алгоритма без потери надёжности. Zab, будучи менее универсальным, предоставил отрасли готовое решение для целого класса координационных сервисов, где требуются порядок и надежность, но можно ограничиться одной мастер-репликой.
На практике выбор алгоритма и системы зависит от требований приложения. Если нужна подтверждённая годами работа в крупных кластерах Hadoop/Kafka – часто берут ZooKeeper (Zab). В облачных и контейнерных средах с микросервисами и динамической конфигурацией – обычно etcd (Raft) или Consul (Raft + доп. возможности). В критически важных финансовых системах или глобально распределённых БД могут применяться адаптации Paxos. Все три алгоритма демонстрируют принцип кворумного консенсуса: для прогресса решения нужно пересечение большинства узлов, что даёт стойкость к расколу сети ценой остановки операций при потере связи с большинством (свойство CP). Это осознанный компромисс для гарантий консистентности.
При внедрении консенсус-алгоритма важно учесть практические аспекты: требования к не превышению задержек (таймауты в Raft должны быть настроены под сеть), надежное хранилище логов (диски SSD, защита от потери данных), мониторинг состояния кластера (чтобы выявлять деградацию прежде, чем потерян кворум). Инструменты вроде etcd и Consul заметно упрощают эту задачу, предоставляя готовый сервис, но разработчику всё равно нужно понимать пределы возможностей: например, что кластер из 3 узлов не переживёт остановки 2 из них, что при сетевом разделе часть приложений может временно стать недоступной из-за отсутствия лидера, и т.д.
Современные тренды показывают, что консенсус-протоколы становятся основой Self-healing инфраструктуры. Kubernetes сам полагается на etcd; сервис-меши и контрольные плоскости (control plane) распределённых систем всё чаще встраивают маленькие Raft-кластеры для отказоустойчивости. Даже в блокчейнах, хоть там и другие допущения (наличие византийских узлов), идеи классического консенсуса прослеживаются (PBFT, Casper, Tendermint – это расширения консенсуса на случай византийских ошибок).
Подводя итог, знание Paxos, Raft, Zab и понимание их реализации «под капотом» важно для архитекторов и разработчиков распределённых систем. Эти алгоритмы – своего рода «движок» надежности: невидимый пользователю, но обеспечивающий правильную работу множества высоконагруженных и критических сервисов. Выбирая готовое решение (etcd, ZooKeeper, Consul и т.п.), инженеру следует ориентироваться на требования консистентности, среды деплоя и функциональные возможности. А глубокое понимание алгоритмов позволяет лучше диагностировать проблемы (например, причины замедления коммитов или сплит-брейна) и принимать обоснованные решения при проектировании новой системы, которой требуется формально проверенная устойчивость к сбоям и согласованность данных.
