Итоги модуля: Архитектура 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.

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

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

Цепочка: 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 для потребителей.

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

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