Итоги модуля: Архитектура Kafka

Этот модуль заложил фундамент для понимания Kafka. Разберём ключевые концепции и их взаимосвязь.

Что вы изучили в этом модуле

Урок 1: Распределённый Commit Log

Kafka — это append-only commit log. Этим определяется всё остальное:

Записи добавляются только в конец, никогда не изменяются.
Offset — монотонный целочисленный адрес записи в пределах партиции. Разные consumer groups читают один и тот же offset независимо.
Kafka оптимизирована для последовательного I/O — миллионы записей в секунду при правильной конфигурации.
Данные хранятся до истечения retention.ms или retention.bytes. Replay — прочитать с offset 0.

Урок 2: Брокеры, Топики, Партиции

Физическая реальность commit log в кластере:

Брокер = JVM-процесс с node.id и process.roles (broker/controller/combined).
Топик = именованный поток, разбитый на партиции. CLI: kafka-topics.sh --bootstrap-server.
Партиция = единица параллелизма. Порядок гарантирован только внутри одной партиции.
num.partitions — только увеличивать, не уменьшать. replication.factor=3 для production.

Урок 3: Репликация и ISR

Механизм надёжности хранения:

ISR = реплики в синхронизации с лидером (в пределах replica.lag.time.max.ms).
LEO (Log End Offset) — следующий свободный offset каждой реплики.
HW (High Watermark) = min(LEO всех ISR-реплик). Потребитель читает только до HW.
acks=all + min.insync.replicas=2 — правильная комбинация для production durability.

Урок 4: KRaft контроллер

Управление метаданными кластера без ZooKeeper:

KRaft — встроенный Raft-протокол. ZooKeeper удалён в Kafka 4.0.
Metadata log — event-sourced append-only лог всех изменений кластера.
Quorum: нечётное число voter-узлов (3 или 5). Кворум = большинство.
Epoch fencing — команды с устаревшим epoch отклоняются. Защита от split-brain.
kafka-metadata-quorum.sh describe --status — инструмент мониторинга KRaft.

Урок 5: Rack Awareness

Защита от стоечных и зональных сбоев:

broker.rack — строка-идентификатор стойки или AZ.
При RF=3 и 3 rack — каждая реплика в отдельной rack.
В облаке: broker.rack = availability_zone_name.
Действует только при создании топика; существующие топики требуют ручной reassign.

Как концепции связаны между собой

Архитектурная карта: Kafka Module 01

Producer

ProduceRequest (acks=all)

Partition Leader

FetchRequest (ISR replication)

ISR Follower

High Watermark advance

Consumer (читает до HW)

metadata (leader, ISR)

KRaft Controller

broker.rack

Rack-Aware Placement

Что важно помнить для экзамена

TIP

Эти связи часто проверяются в экзаменационных вопросах — убедитесь, что понимаете причинно-следственные отношения, а не просто определения.

Цепочка: acks → ISR → HW → Consumer visibility

Producer ack получен от ISR-реплик → HW продвигается → Consumer видит новые записи.

Если ISR = 1 и min.isr = 1 → acks=all = acks=1 → нет дополнительных гарантий.

Цепочка: Kafka 4.0 = KRaft only

zookeeper.connect не существует. kafka-topics.sh --zookeeper не существует. Используйте --bootstrap-server.

Цепочка: broker.rack → rack-aware assignment → отказоустойчивость

broker.rack задаётся один раз при настройке. Влияет только на новые топики. Существующие партиции требуют ручной reassign.

Цепочка: LEO per replica → HW = min(ISR LEOs) → потребитель ждёт

HW не продвигается быстрее самой медленной ISR-реплики. Медленный фолловер = staleness для потребителей.

Типичные ошибки

ISR = 1 + acks=all без min.insync.replicas=2 — иллюзия надёжности. Реально: один узел отказа = потеря данных.
Слишком много партиций — >4000 на брокер создаёт overhead для leader election и metadata management.
Не устанавливать broker.rack в production — реплики случайно распределяются, не учитывая физическую топологию.
Уменьшать num.partitions — невозможно без пересоздания топика и потери данных.
Думать, что порядок гарантирован в топике — нет, только в партиции.

Проверка знанийKnowledge check

Продюсер записал сообщение с acks=all. Broker 1 — лидер, Broker 2 и Broker 3 — фолловеры (все в ISR). Broker 3 медленно реплицирует из-за GC pause. Через 30 секунд Broker 3 выбывает из ISR (остаётся ISR=[1,2]). min.insync.replicas=2. Что изменилось для продюсера и что изменилось для потребителя?

ОтветAnswer

Для продюсера: ничего критичного не изменилось. acks=all по-прежнему требует подтверждения от всех ISR-реплик, теперь их 2 (Broker 1 и Broker 2). min.insync.replicas=2 соблюдается (ISR=2 >= min.isr=2). Записи продолжают приниматься. Если ISR уменьшится до 1 (ещё один брокер выпадет), продюсер начнёт получать NotEnoughReplicasException. Для потребителя: HW может немного вырасти — медленный Broker 3 больше не тормозит продвижение HW. Без Broker 3 в ISR, min(LEO[1], LEO[2]) вместо min(LEO[1], LEO[2], LEO[3]). Это потенциально ускоряет видимость новых записей для потребителя.