Есть ли понимание принципов работы с очередями сообщений в Kafka

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

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

Как отвечать

Опорные понятия:

• топик и партиции: каждая партиция это упорядоченный лог, в который только дописывают. Порядок гарантирован только внутри партиции. Партицию выбирают по хэшу ключа, поэтому события одного заказа с одним ключом придут по порядку;
• хранение: сообщение не удаляется после чтения. Оно живёт по retention.ms (по умолчанию 7 дней) или до компакции, и его можно перечитать, сдвинув offset;
• consumer group: партицию в группе читает один консьюмер, лишние консьюмеры сверх числа партиций простаивают. Позицию группа коммитит в служебный топик __consumer_offsets;
• репликация: replication.factor, ISR, min.insync.replicas. С Kafka 3.0 продюсер по умолчанию работает с acks=all и enable.idempotence=true;
• семантика: коммит offset до обработки даёт at-most-once, после обработки at-least-once. Exactly-once внутри Kafka держится на транзакциях (transactional.id, у консьюмера isolation.level=read_committed). Если результат уходит во внешнюю базу, дубли отсекает идемпотентный обработчик.

Из Java-практики: KafkaConsumer не потокобезопасен, а если обработка пачки дольше max.poll.interval.ms (по умолчанию 5 минут), консьюмера исключат из группы и начнётся ребалансировка. В Spring Kafka это @KafkaListener и KafkaTemplate, сбойные сообщения уходят в DLT через DefaultErrorHandler с DeadLetterPublishingRecoverer. В Kafka 4.0 ZooKeeper убран, метаданные хранит KRaft.

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

Говорят, что сообщение удаляется после прочтения, как в RabbitMQ.

Обещают порядок по всему топику. Он есть только внутри партиции, а смена числа партиций меняет распределение ключей.

Считают exactly-once галочкой в конфиге. Без идемпотентной обработки на стороне сервиса дубли при ребалансировке неизбежны.