Какая структура у Kafka брокера

Что проверяют

Знаете ли вы, что происходит внутри брокера, а не только словарь «топик, партиция, консьюмер». Следом почти всегда идут репликация и гарантии: что значит acks=all и как брокер решает, что реплика отстала.

Как отвечать

Брокер это процесс на JVM, который хранит партиции и обслуживает запросы клиентов. Внутри несколько слоёв:

• сеть: акцепторы принимают соединения, сетевые потоки (num.network.threads) читают запросы и кладут в общую очередь;
• обработчики: пул num.io.threads разбирает очередь и работает с хранилищем;
• лог: партиция это каталог на диске с сегментами. Сегмент состоит из файла .log, индекса смещений .index и индекса по времени .timeindex. Новый сегмент начинается по log.segment.bytes (по умолчанию 1 ГБ) или по времени, старые удаляются по retention (по умолчанию 7 дней) либо уплотняются при cleanup.policy=compact;
• реплики: у партиции один лидер и фолловеры, которые сами тянут с него данные. Успевающие реплики образуют ISR, порог отставания задаёт replica.lag.time.max.ms;
• purgatory: отложенные запросы, например запись с acks=all, ждущая подтверждения ISR;
• координаторы: групп потребителей (смещения в топике __consumer_offsets) и транзакций.

Метаданные кластера живут в KRaft: кворум контроллеров на Raft хранит их в топике __cluster_metadata. В Kafka 4.0 ZooKeeper удалён полностью, роль узла задаётся process.roles.

Скорость брокер берёт из последовательной записи и страничного кэша ОС: данные не держатся в куче JVM, а отдача консьюмерам идёт через zero-copy sendfile, если не включён TLS.

Где спотыкаются

Рассказывают про ZooKeeper как про обязательную часть. Это устаревшая картина, в текущих версиях его заменил KRaft.

Считают, что брокер сам рассылает сообщения потребителям. Модель pull: консьюмер запрашивает данные с нужного смещения и сам коммитит прогресс.

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