Протокол ZAB¶

Протокол ZAB (ZooKeeper Atomic Broadcast) — это алгоритм консенсуса, используемый для обеспечения согласованности данных в распределённых системах, в частности в системе Apache ZooKeeper. Он обеспечивает надёжную репликацию данных между узлами кластера, гарантируя, что все операции записи упорядочены и применяются в единой последовательности, что позволяет достичь строгой согласованности (linearizability) в условиях отказов узлов и сетевых задержек.

¶История

Протокол ZAB был разработан в рамках проекта Apache ZooKeeper, который, в свою очередь, возник из внутренних разработок компании Yahoo! в 2008 году. Изначально ZooKeeper создавался как сервис координации для распределённых приложений, работающих в больших кластерах. Основной задачей было обеспечение надёжного хранения и синхронизации конфигурационных данных, а также реализация примитивов синхронизации (блокировок, очередей). Для этого требовался протокол, способный гарантировать целостность данных даже при сбоях лидера или потере связи между узлами.

Первая версия протокола была описана в техническом отчёте Yahoo! (2009 год) и в последующей статье «ZooKeeper: Wait-free coordination for Internet-scale systems» (2010 год). В отличие от классического алгоритма Paxos, который был сложен для понимания и реализации, ZAB был спроектирован как более простой и специализированный протокол, ориентированный на конкретную задачу ZooKeeper — атомарную рассылку сообщений в условиях частичной синхронности.

¶Основные принципы

Протокол ZAB работает в модели с одним лидером (leader) и несколькими последователями (followers). Все операции записи обрабатываются лидером, который затем распространяет изменения на последователей. Это обеспечивает единый порядок операций.

¶Атомарная рассылка

Ключевое свойство ZAB — атомарность. Это означает, что либо все узлы кластера получают и применяют одно и то же обновление, либо ни один из них не применяет его. Если лидер отправляет запрос на изменение, но не получает подтверждения от большинства последователей, операция считается неудавшейся и откатывается.

¶Упорядочивание сообщений

ZAB гарантирует глобальный порядок сообщений: все операции записи, которые были подтверждены (committed), применяются на всех узлах в одной и той же последовательности. Это достигается за счёт того, что лидер присваивает каждой операции уникальный идентификатор (Zxid — ZooKeeper Transaction ID), который состоит из двух частей: эпохи (epoch) и счётчика (counter). Эпоха меняется при смене лидера, а счётчик увеличивается с каждой новой операцией в рамках одной эпохи.

¶Компоненты протокола

Протокол ZAB можно разделить на три основные фазы:

¶Фаза 1: Выборы лидера (Leader Election)

При запуске кластера или при отказе текущего лидера все узлы (серверы) инициируют процесс выборов. Каждый узел голосует за себя или за другой узел, используя алгоритм Fast Leader Election (FLE). Победителем становится узел, который получил поддержку большинства (кворума) и имеет самую свежую копию данных (наибольший Zxid). После того как лидер выбран, он переходит к следующей фазе.

¶Фаза 2: Восстановление (Recovery)

После выборов лидер должен синхронизировать данные с последователями. Он отправляет им свой журнал транзакций (log), содержащий все операции, которые были подтверждены до его избрания. Последователи сравнивают свои данные с данными лидера и применяют недостающие изменения. Этот этап гарантирует, что все узлы видят одинаковое состояние системы.

¶Фаза 3: Широковещательная рассылка (Broadcast)

После завершения восстановления лидер начинает принимать новые запросы от клиентов. Он создаёт предложение (proposal), присваивает ему Zxid и отправляет его всем последователям. Последователи записывают предложение в свой журнал и отправляют подтверждение (ack) лидеру. Как только лидер получает подтверждения от большинства последователей (включая себя), он фиксирует (commit) операцию и отправляет всем узлам сообщение о фиксации. После этого последователи применяют изменение к своей копии данных.

¶Отличия от других протоколов

¶Paxos

Протокол ZAB часто сравнивают с Paxos. Оба решают задачу консенсуса, но имеют различия:

• Специализация: ZAB оптимизирован для рассылки последовательности операций, а не для единичного решения, как Paxos.
• Простота: ZAB использует модель «один лидер», что упрощает реализацию по сравнению с Paxos, который может работать с несколькими лидерами.
• Восстановление: ZAB имеет явную фазу восстановления, которая гарантирует, что новый лидер обладает полными и актуальными данными.

¶Raft

Raft — ещё один популярный протокол консенсуса, который также использует модель с лидером. ZAB и Raft имеют схожие цели, но различаются в деталях:

• Выборы лидера: В Raft выборы основаны на случайных таймаутах, что снижает вероятность конфликтов. В ZAB используется алгоритм FLE, который может быть более быстрым, но требует большего числа сообщений.
• Управление журналом: В Raft записи журнала имеют строгий порядок, и лидер может перезаписывать записи последователей. В ZAB также используется строгий порядок, но с механизмом эпох.
• Сложность: Raft считается более простым для понимания и реализации, в то время как ZAB имеет более сложную логику восстановления.

¶Применение

Протокол ZAB является основой работы Apache ZooKeeper, который используется в различных распределённых системах:

• Управление конфигурацией: ZooKeeper хранит конфигурационные данные для кластеров Hadoop, Kafka, HBase и других систем.
• Сервис синхронизации: Обеспечивает реализацию распределённых блокировок, очередей и барьеров.
• Обнаружение сервисов: Позволяет динамически регистрировать и находить сервисы в кластере.
• Выборы лидера: Используется для выбора активного узла в системах с репликацией (например, в Apache Kafka).

¶Критика и ограничения

Несмотря на широкое распространение, протокол ZAB имеет некоторые ограничения:

• Производительность: Все операции записи проходят через лидера, что создаёт узкое место. При высокой нагрузке на запись лидер может стать бутылочным горлышком.
• Сложность реализации: Реализация ZAB требует тщательного управления состоянием и обработки сбоев, что может быть сложным для разработчиков.
• Зависимость от кворума: Для работы кластера необходимо наличие большинства узлов. При потере кворума (например, из-за сетевого разделения) кластер перестаёт обрабатывать запросы на запись.

¶Интересные факты

• Название «ZAB» расшифровывается как «ZooKeeper Atomic Broadcast», что подчёркивает его связь с проектом ZooKeeper.
• Протокол ZAB был одним из первых протоколов консенсуса, реализованных в открытом доступе, что способствовало его популярности в сообществе разработчиков распределённых систем.
• В отличие от Paxos, который часто описывается как «протокол для академиков», ZAB был спроектирован с учётом практических требований и простоты интеграции.

¶Источники

• Hunt, P., Konar, M., Junqueira, F. P., & Reed, B. (2010). ZooKeeper: Wait-free coordination for Internet-scale systems. Proceedings of the 2010 USENIX Annual Technical Conference.
• Junqueira, F. P., & Reed, B. (2013). ZooKeeper: Distributed Process Coordination. O'Reilly Media.
• Официальная документация Apache ZooKeeper.