Kafka Broker

Broker — процесс Kafka, который хранит сегменты партиций и обслуживает запросы клиентов и других брокеров. bootstrap.servers — список начальных адресов для получения metadata. Неверно считать каждый broker отдельным “bootstrap-сервером”: клиент может начать с одного доступного адреса, а затем подключается к лидерам нужных партиций.

Партиция на диске

Партиция — append-only log из сегментов. Рядом с log-файлами находятся индексы, ускоряющие поиск по offset и timestamp. Старые сегменты удаляются по retention времени/размера либо очищаются log compaction — в зависимости от политики топика.

У реплицированной партиции есть:

  • leader — принимает обычные чтения и записи;
  • followers — подтягивают записи у лидера;
  • ISR — реплики, которые считаются достаточно синхронными;
  • replication factor — общее число копий партиции.

replication.factor=3 не поможет, если все копии оказались на одном отказавшем домене или продюсер подтверждает запись слишком рано.

Контроллеры и KRaft

В актуальной архитектуре метаданные кластера хранятся в KRaft metadata log. Контроллерный quorum выбирает активный controller и координирует изменения metadata. Broker и controller могут быть совмещены в небольшой установке или разделены в промышленном кластере.

ZooKeeper выполнял координацию в прежней архитектуре. В современных заметках важно различать историческую схему и KRaft, иначе диагностика начинается с компонента, которого в кластере нет.

Как проходит запись

sequenceDiagram
    participant P as Producer
    participant L as Leader
    participant F as Follower
    P->>L: produce(record)
    L->>L: append
    F->>L: fetch
    L-->>F: records
    F->>F: append
    L-->>P: ack по настройке acks

При acks=all лидер ждёт подтверждаемого состояния всех текущих ISR, а не вообще всех настроенных реплик. Если ISR меньше min.insync.replicas, запись отклоняется: доступность сознательно обменивается на долговечность.

Что смотреть при аварии

kafka-topics --bootstrap-server localhost:9092 --describe --topic orders
kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group billing

Проверяю лидеров и ISR, недореплицированные партиции, заполнение диска, задержки запросов, сетевые ошибки и consumer lag. Рост lag не доказывает проблему брокера: причиной может быть медленный обработчик.

Типичные сбои

  • В advertised listeners указан адрес, недоступный клиенту: bootstrap проходит, дальнейшее соединение падает.
  • На диске закончилось место из-за неверной retention.
  • ISR сжался, и продюсер с acks=all начал получать ошибки.
  • Слишком много партиций увеличило нагрузку на metadata, файловые дескрипторы и восстановление.
  • Лидер доступен, но одна из followers давно отстаёт.

Вопросы для собеседования

Кто принимает запись в партицию? Её leader; followers реплицируют данные.

Что такое ISR? Набор реплик, считающихся синхронными с лидером по правилам кластера.

Зачем клиенту bootstrap.servers? Получить metadata и узнать реальные endpoints лидеров; это не балансировщик всех запросов.

Чем retention отличается от compaction? Retention удаляет старые сегменты по времени/размеру; compaction сохраняет актуальные значения для ключей, не превращая топик в обычную таблицу.

Где теперь хранится metadata вместо ZooKeeper? В KRaft metadata log, которым управляет controller quorum.

См. Kafka, Kafka Producer, Команды Kafka.