KRaft и почему Kafka быстрая

В прошлом уроке мы сравнили Kafka с RabbitMQ, Pulsar и Redpanda. Kafka часто выбирают за скорость: кластер «Гонца» из трёх скромных серверов спокойно примет сотни тысяч событий в секунду. Сегодня заглянем под капот и разберём две вещи. Кто в кластере решает, какой брокер лидер. И почему лог на обычном диске работает так быстро.

Диспетчерская и журнал смен

В диспетчерской «Гонца» есть журнал смен. В него записывают всё, что меняется в городе: курьер вышел на линию, курьер сломал велосипед, зону «Центр» передали другому старшему. Кто прав, решает не память диспетчера, а журнал: что записано, то и есть.

Журнал ведут три диспетчера. Каждую запись они подтверждают большинством: если двое из трёх согласны, запись принята. Один диспетчер может заболеть, и диспетчерская продолжит работать. Двое заболели, и новые решения принимать некому, пока кто-то не вернётся.

Так устроено управление кластером Kafka.

Брокеры и контроллеры

В кластере Kafka у серверов две роли.

Брокеры хранят партиции и обслуживают продюсеров и консьюмеров. Их мы видели весь блок.

Контроллеры управляют кластером: знают, какие брокеры живы, где лежат партиции, кто лидер и кто в ISR. Когда брокер замолчал, именно контроллер огораживает его и назначает новых лидеров, как в уроке про репликацию.

Все решения контроллеры записывают в служебный лог, журнал метаданных. Он устроен как обычная партиция Kafka и лежит на диске в папке __cluster_metadata-0. Брокеры читают этот журнал и так узнают, что изменилось.

KRaft: кворум контроллеров

Контроллеров обычно три или пять, всегда нечётное число. Они договариваются по протоколу KRaft, это вариант известного алгоритма Raft. Группу контроллеров называют кворумом. Один из них лидер: он принимает решения и пишет их в журнал. Запись считается принятой, когда её подтвердило большинство.

Отсюда простая арифметика: три контроллера переживают падение одного, пять переживают падение двух. Если большинства нет, брокеры какое-то время продолжают работать по последним известным лидерам, но новых решений кластер принять не может: упавшего брокера огородить некому, новый топик создать нельзя.

До Kafka 4.0 эту работу делал отдельный сервис ZooKeeper, и в старых инструкциях ты встретишь его настройки. С версии 4.0 ZooKeeper не поддерживается вовсе, KRaft единственный режим.

В уроке про первый кластер мы запускали один контейнер. В нём брокер и контроллер живут в одном процессе: в настройках стоит process.roles=broker,controller. Посмотреть на кворум можно утилитой kafka-metadata-quorum.sh. Вот её вывод на нашем контейнере с Kafka 4.3.1:

kafka-metadata-quorum.sh --bootstrap-server localhost:9092 describe --status

ClusterId:              5L6g3nShT-eMCtK--X86sw
LeaderId:               1
LeaderEpoch:            1
HighWatermark:          25
MaxFollowerLag:         0
MaxFollowerLagTimeMs:   0
CurrentVoters:          [{"id": 1, "endpoints": ["CONTROLLER://localhost:9093"]}]
CurrentObservers:       []

CurrentVoters это контроллеры, которые голосуют. Здесь он один, узел 1, и он же лидер. HighWatermark знаком по уроку про репликацию: до этой записи журнал метаданных подтверждён. На проде у «Гонца» будет три голосующих контроллера на отдельных машинах, а брокеры станут наблюдателями, CurrentObservers.