Что происходит с сообщением в Kafka после его прочтения

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

Понимаете ли вы, что Kafka это журнал, а не очередь в духе RabbitMQ, где подтверждённое сообщение исчезает. Для тестировщика отсюда главное: сообщения можно перечитать, а повторы и пропуски зависят от того, когда потребитель фиксирует offset. Следом обычно спрашивают, как проверить, что сервис не обработает сообщение дважды.

Как отвечать

После чтения с сообщением не происходит ничего. Оно остаётся в партиции, а меняется только позиция группы потребителей:

• offset: порядковый номер сообщения внутри партиции. Группа хранит, до какого места дочитала, во внутреннем топике __consumer_offsets. Kafka не знает, обработано ли сообщение, она знает только закоммиченный offset;
• коммит: по умолчанию enable.auto.commit=true, offset фиксируется раз в auto.commit.interval.ms, это 5 секунд. Сервис упал между обработкой и коммитом, и после рестарта часть сообщений придёт повторно. Отсюда гарантия «хотя бы один раз» и требование к идемпотентной обработке;
• другие группы: каждая группа читает топик независимо со своим offset. Сервис уведомлений и сервис аналитики получат одно и то же сообщение;
• удаление: сообщения уходят по политике хранения, а не по факту чтения. retention.ms по умолчанию 7 дней, retention.bytes без ограничения. Удаляются целые сегменты, поэтому сообщение может прожить чуть дольше срока. При cleanup.policy=compact остаётся последнее значение по каждому ключу.

Для проверки пригодятся kafka-console-consumer.sh или kcat для просмотра топика, kafka-consumer-groups.sh --describe для лага группы и --reset-offsets --to-earliest на остановленной группе, чтобы прогнать сценарий заново на тех же данных.

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

Говорят, что после чтения сообщение удаляется или помечается прочитанным. Это модель классических брокеров очередей, в Kafka её нет.

Не учитывают auto.offset.reset. Новая группа по умолчанию стартует с latest и не видит сообщений, отправленных до подключения, поэтому тест «отправили, потом подписались» ложно краснеет.

Не проверяют повторную доставку. Сценарий «убили консьюмер после обработки, но до коммита» должен быть в тест-плане, иначе дубли вылезут на проде.