Обзор KRaft
Обзор
Kafka Raft (KRaft) — это протокол, основанный на алгоритме консенсуса Raft, при помощи которого осуществляется управление метаданными кластера Kafka. KRaft организовывает хранение информации о конфигурации кластера, обеспечивает синхронизацию брокеров Kafka при репликации данных без использования механизмов выбора лидера и хранения метаданных, предоставляемых ZooKeeper.
|
ПРИМЕЧАНИЕ
Возможность включения режима KRaft существует начиная с версии Kafka 3.6.2. |
Преимущества KRaft
Главная характеристика KRaft заключается в отсутствии сервиса-посредника, что влечет за собой следующие преимущества:
-
Быстрое и эффективное хранение и распространение метаданных: обновления отправляются непосредственно в кворум контроллера, устраняя дополнительный узел передачи (ZooKeeper).
-
Брокеры и контроллеры могут хранить метаданные локально в своей кеш-памяти и обращаться к ним, не используя соединение с внешним сервисом.
-
Уменьшение задержек при завершении работы брокеров.
-
Предполагается, что протокол KRaft позволит значительно увеличить предел для количества партиций для одной ноды и целого кластера.
Кворум контроллера
Основная концепция KRaft основана на создании кворума контроллера — набора специализированных брокеров, которые отвечают за хранение и своевременное обновление метаданных кластера.
Для назначения контроллеров в Kafka используется параметр process.roles cо значением controller.
Кворум контроллера обслуживает только внутренний топик __cluster_metadata с метаданными Kafka. Топик содержит одну партицию, в которую записывается вся информация с текущим состоянием брокеров Kafka, а также топиков и партиций. Лидер партиции — активный контроллер — выбирается на основе алгоритма консенсуса Raft путем голосований за эпоху лидера. Активный контроллер кворума отвечает за запись изменений метаданных в топик __cluster_metadata.
Контроллеры, не являющиеся лидером, хранят точную копию топика с метаданными как in-sync replicas (ISR) и имеют право голосовать за новую эпоху лидера. В результате выборов каждый из этих избирателей может стать лидером.
Брокеры, у которых параметр process.roles имеет значение broker, не могут голосовать за эпоху лидера, они являются наблюдателями (observer). Наблюдатели работают как обычные брокеры Kafka, но при этом хранят копию топика __cluster_metadata, перезаписывая каждый раз в собственную кеш-память состояние метаданных кластера при изменении топика.
Также активный контроллер осуществляет отслеживание состояния всех контроллеров и брокеров при помощи тайм-аутов и heartbeat-сообщений, которые посылают брокеры. При остановке брокера лидер перераспределяет партиции на другие брокеры и обновляет информацию о них в топике метаданных.
Для согласования реплик используется маркер high water mark (HWM) — наибольшее смещение в логе, которое было записано во все ISR. Последователи кешируют его значение и обновляют при каждом изменении лога лидера, таким образом поддерживая согласованное состояние кластера. При смене лидера все партиции последователей усекают свой журнал до HWM, зафиксированого новым лидером, и все сообщения выше HWM становятся нечитаемыми. После усечения журнала последователь может продолжить репликацию любых новых сообщений от лидера. Как только все новые сообщения реплицируются на большинство узлов, HWM увеличивается.
Кроме параметра process.roles, для брокеров кластера Kafka, настраиваемого для работы в режиме KRaft, должны быть определены параметры:
-
controller.quorum.voters.roles — адреса узлов, участвующих в кворуме контроллера.
-
node.id — идентификатор узла, который должен быть уникальным целым числом и назначаться во время установки/расширения. Не может совпадать с идентификатором любого другого брокера или контроллера в кластере.
-
controller.listener.names — разделенный запятыми список имен слушателей, используемых контроллером. При общении с кворумом контроллера брокер в режиме KRaft всегда будет использовать первого слушателя в этом списке.
-
metadata.log.dir — директория для хранения метаданных кластера. Имя директории не должно совпадать с любым каталогом брокера, по умолчанию /kafka-meta.
Алгоритм Raft
Обзор
Алгоритмы консенсуса Raft и ZAB, использующийся в ZooKeeper, имеют следующие концептуальные сходства:
-
единственный лидер, отвечающий за обработку данных, в любой момент времени;
-
отдельные процессы для выборов лидера и репликации журналов;
-
общая нацеленность на обеспечение согласованности данных в распределенных системах.
Архитектура Raft имеет более простую реализацию, в которой выделены следующие роли для работы узлов:
-
Лидер кластера, который обрабатывает запросы клиента и контролирует репликацию данных.
-
Кандидат, пытающийся стать лидером.
-
Последователь, записывающий сообщения и обрабатывающий запросы от лидера и кандидатов.
Голосование
Лидер выбирается случайным образом при первом запуске, а остальные узлы начинают свою работу в качестве последователей.
Лидер отслеживает работоспособность последователей при помощи тайм-аутов и периодических heartbeat-сообщений, а также отправляет свои heartbeat-сообщения вместе с сообщениями топиков (если они есть) или без них.
Если последователь в течение тайм-аута не получает heartbeat-сообщений от лидера, он становится кандидатом в лидеры.
Каждый кандидат отправляет остальным узлам запрос на лидерство и принимает такие же запросы от остальных. Кандидат, получивший большинство голосов, становится лидером. Лидер выбирается на период, так называемый срок. Срок идентифицируется как эпоха — число, которое увеличивается монотонно с каждым новым лидером.
Репликация сообщений
Лидер отправляет всем последователям запрос на добавление новой записи и считает транзакцию успешной только после получения от большинства узлов подтверждения записи сообщения.
Сообщения всегда добавляются последовательно.
Если внешний клиент подключается к кластеру через последователя, запрос все равно перенаправляется лидеру.
KRaft
Дополнительно в протоколе KRaft появляется способ хранения метаданных, основанный на протоколе репликации логов Kafka, где и используется кворум контроллера. Основной принцип заключается в том, что каждый брокер кластера стремится хранить реплику топика метаданных и не требует соединения с ZooKeeper для получения состояния кластера (лидеры партиций топиков, новые брокеры и т.д.) и, соответственно, задержек и значительного объема памяти, так как процесс хранения метаданных как лога является частью работы алгоритмов Kafka.
Управление метаданными
Запись метаданных
Каждый новый брокер или контроллер, который присоединяется к кластеру, запрашивает копию внутреннего топика __cluster_metadata и создает его реплику, одновременно кешируя данные топика, т.е. сохраняет данные о полном состоянии кластера.
Если брокер запускается после сбоя, он считывает самые последние изменения, доступные в его кеше метаданных. После этого он запрашивает у активного контроллера события, произошедшие с момента последнего обновления в __cluster_metadata, и в ответ получает последние изменения в виде снепшотов состояния кластера.
Репликация метаданных
Для Kafka, работающей в режиме KRaft, HWM отслеживается и учитывается лидером для общего количества реплик топика метаданных (не только для реплик ISR, как в обычной Kafka).
HWM не может быть увеличена, пока все сообщения, записанные лидером, не будут сохранены большинством реплик. Если произошла смена лидера, эпоха увеличивается. Для согласования своих логов с лидером последователи отправляют запрос, содержащий последнее смещение и последнюю эпоху, во время которой были записаны сообщения.
На основании таких запросов лидер отслеживает работоспособность брокеров и в ответ отправляет информацию о новой эпохе и последнем смещении. Далее реплики догоняют лидера или отсекают свой лог до HWM, переданного лидером. После того, как большинство брокеров подтверждает запись последнего смещения, HWM увеличивается. После усечения журнала ведомый может продолжить репликацию любых новых сообщений от лидера.
KRaft в ADS
Начиная с версии ADS 3.6.2.2.b1 доступна установка сервиса Kafka в режиме KRaft с использованием интерфейса ADCM. Данный способ автоматически устанавливает для брокеров необходимые параметры.
|
ВНИМАНИЕ
|