Как устроен брокер сообщений Kafka

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

Понимает ли тестировщик модель доставки: где гарантируется порядок, как считается отставание, что происходит при перезапуске потребителя. Это вопрос про способность тестировать систему на Kafka, а не пересказать схему из статьи.

Как отвечать

Базовые сущности:

• Топик это логический поток, разбитый на партиции. Партиция это append-only лог на диске, каждое сообщение получает offset, монотонный номер внутри партиции. Глобального порядка по топику нет, порядок гарантирован только внутри одной партиции.
• Продюсер выбирает партицию: по хешу ключа, если ключ задан, иначе sticky-распределением батчами. Отсюда правило: сообщения одной сущности отправляют с одинаковым ключом, тогда их относительный порядок сохранится.
• Консюмер читает и коммитит offset. Группа консюмеров делит партиции между участниками: одну партицию внутри группы читает ровно один консюмер, поэтому число партиций это потолок параллелизма, лишние консюмеры простаивают.
• Ребалансировка перераспределяет партиции при входе или выходе участника, на это время чтение приостанавливается.

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

Надёжность:

• партиция реплицируется, у неё есть лидер и фолловеры, множество догнавших реплик называется ISR;
• acks=all вместе с min.insync.replicas=2 даёт запись, подтверждённую после попадания в несколько реплик. acks=1 теряет данные, если лидер упал сразу после ответа продюсеру;
• хранение по времени и размеру (retention.ms) либо компакция (cleanup.policy=compact), при которой остаётся последнее значение на ключ.

Семантика доставки по умолчанию at-least-once, то есть дубликаты возможны и потребитель обязан быть идемпотентным. Exactly-once достигается идемпотентным продюсером плюс транзакциями и isolation.level=read_committed на чтении, и действует только в пределах Kafka, а не до внешней базы.

Что из этого проверяет QA:

• дубликаты и порядок при повторных отправках: повторить сообщение и убедиться, что вторая запись в базе не появилась;
• поведение при ребалансировке и рестарте потребителя: ничего не потеряно, ничего не обработано дважды с побочным эффектом;
• consumer lag как основная метрика: растущее отставание это ранний признак деградации;
• ядовитое сообщение: битый payload не должен вечно блокировать партицию, нужна DLQ или пропуск с алертом;
• совместимость схем через Schema Registry: новый продюсер не должен ломать старых потребителей;
• окружение для тестов: Kafka в Testcontainers вместо общего стенда, где чужие сообщения ломают проверки.

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

Описывают ZooKeeper как действующий компонент и обещают гарантию порядка «в топике» вместо партиции. Ещё называют exactly-once поведением по умолчанию, из-за чего в тест-плане вовсе нет проверок на дубликаты.