Гайды
RabbitMQ vs Kafka: что выбрать
Матрица моделей, когда нужен лог и replay, когда очередь задач и маршрутизация, гибриды и пять вопросов для решения.
~8 мин чтения
RabbitMQ vs Kafka: что выбрать
Оба продукта двигают сообщения между сервисами, но модель и компромиссы разные. Ниже — практичные критерии без «Kafka на всё». Детали: Apache Kafka: топики, партиции и оффсеты, RabbitMQ: установка и обменники; лёгкая альтернатива — Введение в NATS.
1. Краткая матрица
| Критерий | Kafka | RabbitMQ |
|---|---|---|
| Модель | Распределённый лог (топики/партиции) | Брокер очередей (exchange → queue) |
| Потребители | «Перематывают» лог по offset | Сообщение удаляется после ack (классика) |
| Retention | Долго хранить и перечитывать | Короткие буферы; не «data lake» |
| Пропускная способность | Очень высокая для append-only | Высокая, но другой профиль нагрузки |
| Задержка | миллисекунды–десятки | часто ниже для task queue |
| Маршрутизация | Партиция по ключу | Гибкие exchange/bindings |
| Операционка | Тяжёлый кластер, ZK/KRaft | Проще старт, Erlang VM |
2. Когда логичнее Kafka
- Event sourcing / audit / replay — нужен долгий лог и несколько независимых consumer group'ов на один поток.
- Высокий объём событий аналитики, телеметрии, CDC.
- Стриминговая обработка (Kafka Streams, Flink, чтение с offset).
3. Когда логичнее RabbitMQ
- Task queue — job на воркеры, routing по типам задач, priority, TTL.
- Сложная маршрутизация без желания проектировать партиции.
- Низкая задержка RPC-стиль request/reply (
reply-toqueue). - Команда уже знает AMQP и не нужен petabyte-log.
4. Надёжность и семантика
Обе системы дают подтверждения и персистентность при правильной конфигурации. Exactly-once между двумя сервисами в общем случае требует идемпотентности приложения в обеих мирах. В Kafka для «ядовитых» сообщений часто выделяют отдельный топик — DLQ и ошибки.
5. Гибриды
Часто: Kafka как system of record событий, Rabbit как внутренний task bus для микросервиса — не смешивайте без явной границы ответственности.
6. Решение за 5 вопросов
- Нужен ли replay и долгая история? → да = ближе к Kafka.
- Нужен ли маршрут по паттернам и много очередей-подписчиков на один тип? → Rabbit.
- Объём > миллионы msg/сек устойчиво? → чаще Kafka.
- Критична минимальная latency очереди задач? → Rabbit конкурентоспособен.
- Кто будет эксплуатировать кластер ночью? → честно оцените навык.
7. Порядок и дубликаты
Kafka: порядок гарантирован внутри партиции; глобальный порядок — дизайн ключа. Rabbit: порядок в очереди при одном consumer; при нескольких — без доп. ключей порядок не гарантирован. Exactly-once end-to-end в обоих мирах обычно = идемпотентность на потребителе + корректные ack.
8. Наблюдаемость и схемы
В Kafka — broker metrics, consumer lag, under-replicated partitions. В Rabbit — queue depth, unacked, memory/disk alarms. Схемы событий — Avro и Schema Registry для Kafka; в Rabbit чаще JSON + контракты в коде или отдельный реестр сообщений.
9. Альтернативы «вне дихотомии»
Redpanda, Apache Pulsar, облачные Kinesis / Pub/Sub — другие компромиссы по API, операционке и стоимости. Выбирайте после фиксации RPO/RTO, бюджета на managed-сервис и требований к ordering и replay, а не по названию бренда.
Дальше: NATS · Redis Pub/Sub и очереди · Тег «Очереди»