Kafka — append-лог с replay и retention: консьюмер двигает курсор. RabbitMQ — брокер с маршрутизацией: после ack сообщение исчезает. Выбирают под модель потребления и нагрузку, а не по тому, «что уже стоит в кластере».
RabbitMQ rabbitmq собеседование
Kafka — лог, который можно перечитать. Консьюмер двигает курсор. Сообщение остаётся, пока жив retention.
RabbitMQ — очередь задач. Брокер маршрутизирует. После ack сообщение пропадает. Истории в очереди больше нет.
Сравнивать «что быстрее» без паттерна доступа бессмысленно. Kafka хорошо пишет и читает большие логи, держит много независимых читателей, отдаёт историю, CDC, стриминг. Rabbit хорошо раздаёт задачи: гибкий routing, work queues, приоритеты, TTL, когда консьюмеров немного и нужен умный брокер.
Пример. Нужно три сервиса, которые читают одни и те же события за неделю? Kafka: новая группа, сдвиг offset. Нужно раздать короткие задачи воркерам и забыть? Rabbit часто достаточно.
Replay и fan-out
Replay в Kafka — сдвинуть offset или поднять новую группу с earliest, пока retention жив. Вчерашний день на месте, если диск и политика это позволяют.
В Rabbit после ack истории в очереди нет. Replay только если вы сами писали в архив или публикуете заново из БД.
Fan-out в Kafka — новая consumer group на тот же топик. Читает с выбранного offset: часто с текущего конца или с earliest. Fan-out в Rabbit — новая очередь и binding на fanout или topic. Копия пойдёт с момента создания очереди, не «с начала времён», если только вы не настроили отдельное хранение.
- Порядок: Kafka явно партиционирует ключом. Rabbit ближе к FIFO при одном потребителе на очередь. При нескольких competing consumers порядок размывается.
- Операционка: Kafka тяжелее — партиции, диск, rebalance. Rabbit проще начать и сложнее выжать те же мегабайты длинного лога.
- Маршрутизация: у Rabbit она в брокере (topic, headers). У Kafka — в продюсере (ключ, заголовки) и на стороне консьюмера (фильтрация).
// Kafka: billing, search, analytics — три group.id на топик orders
// каждая со своим offset, пока retention жив
// Rabbit: три очереди bound к fanout "orders"
// или одна очередь orders.jobs и competing consumers
// «переиграть вчерашний день» → Kafka (сдвиг offset)
// «раздать короткие задачи воркерам» → Rabbit часто достаточноТри независимых читателя в Kafka — три group.id. В Rabbit — три очереди с binding. Replay вчерашнего дня естественнее в логе.
Когда не тащить чужой паттерн
Короткие job в Kafka «потому что кластер уже есть» можно. Но модель offset и rebalance неудобнее prefetch+ack: воркер думает задачами, лог думает курсорами.
Audit log на месяц в Rabbit без отдельного хранилища потеряет историю в момент ack. Или раздует очереди, если ack не делать. Инструмент должен совпасть с вопросом «можно ли перечитать» и «сколько независимых читателей».
Гибрид нормален: Kafka как шина событий, Rabbit как очередь джоб внутри сервиса. Если границы явные — два инструмента не мешают друг другу.
Типичная ошибка
Сравнивать Kafka и Rabbit по латентности одного сообщения в вакууме. Объявить Kafka очередью задач и удивиться, что rebalance повторил оплату. Ждать от Rabbit replay как от лога. Гибрид без причины — два набора инцидентов.
На собеседовании
Лог против очереди задач. Replay и много независимых читателей — Kafka. Маршрутизация и work queue — Rabbit. Competing consumers в одной очереди — не то же самое, что несколько consumer group.