Когда использовать RabbitMQ

Введение: Универсальный почтальон для задач

Представьте, что у вас есть небольшая, но очень занятая мастерская. Приходят заказы: починить стул, собрать шкаф, покрасить дверь. Заказы нужно распределять между мастерами. Если мастер занят — заказ ждёт. Если заказ срочный — его нужно обработать быстрее. Если заказ нельзя выполнить — нужно сообщить об этом.

RabbitMQ — это идеальный “диспетчер” для таких задач. Он принимает заказы (сообщения), распределяет их между мастерами (воркерами), помнит, кто что делает, не теряет заказы, если мастер заболел (упал), умеет обрабатывать срочные заказы (приоритеты).

RabbitMQ — это классический брокер сообщений для сценариев “очередь задач”. Он не хранит историю (как Kafka), не предназначен для миллионов событий в секунду (хотя справляется с десятками тысяч). Он создан для гибкой маршрутизации, надёжной доставки и сложных паттернов обмена.

Для системного аналитика RabbitMQ — инструмент для средних нагрузок, где нужна сложная логика маршрутизации, гарантии доставки, но не нужно хранить историю событий. Это рабочая лошадка корпоративных интеграций.

Признаки того, что RabbitMQ — хороший выбор

1. Классическая очередь задач (Work Queue)

Вам нужно распределить задачи между несколькими воркерами. Каждая задача должна быть выполнена ровно один раз.

Пример: Обработка заказов, отправка email, генерация отчётов, ресайз изображений.

Почему RabbitMQ:

Характеристики:
  - Сообщение удаляется после обработки (не накапливается)
  - Несколько воркеров читают из одной очереди
  - Round-robin распределение
  - При падении воркера задача возвращается в очередь

Почему не Kafka: Kafka не удаляет сообщения. История будет накапливаться. Нужно управлять offset, что сложно для простой очереди задач.

2. Сложная маршрутизация сообщений

Сообщения должны направляться в разные очереди в зависимости от содержимого.

Пример: Заказы из Москвы — на склад в Москве, заказы из СПб — на склад в СПб. Срочные заказы — в приоритетную очередь. Логи ошибок — в отдельную очередь для аналитики.

Почему RabbitMQ:

Возможности RabbitMQ:
  - Direct exchange: точное совпадение routing key
  - Topic exchange: шаблоны (user.*, order.#)
  - Headers exchange: маршрутизация по заголовкам
  - Fanout exchange: рассылка всем

Почему не Kafka: Kafka не имеет встроенной гибкой маршрутизации. Всё через топики, без сложных правил.

3. RPC (Remote Procedure Call)

Вам нужно вызвать удалённую функцию и получить ответ.

Пример: Сервис A отправляет запрос сервису B, ждёт ответа (синхронно, но через асинхронный брокер).

Почему RabbitMQ:

Паттерн RPC в RabbitMQ:
  1. Клиент создаёт временную очередь (reply_to)
  2. Отправляет сообщение с correlation_id
  3. Ждёт ответа в своей очереди
  4. Сервер обрабатывает, отправляет ответ в reply_to

Почему не Kafka: Kafka не поддерживает request-response нативно. Можно эмулировать, но сложно.

4. Приоритеты сообщений

Одни сообщения важнее других и должны обрабатываться быстрее.

Пример: Заказы VIP-клиентов должны обрабатываться раньше обычных. Критические алерты — раньше информационных логов.

Почему RabbitMQ:

Очередь с приоритетами:
  - x-max-priority: 10
  - Сообщения с priority=10 обрабатываются раньше priority=1

Почему не Kafka: Kafka не имеет приоритетов. Порядок определяется offset.

5. Отложенные сообщения (Delayed delivery)

Сообщение должно быть отправлено не сейчас, а через некоторое время.

Пример: Отправить напоминание через час. Повторить задачу через 5 минут при ошибке. Отложить обработку до определённого времени.

Почему RabbitMQ:

Способы:
  - Плагин rabbitmq_delayed_message_exchange
  - TTL + DLQ (сообщение умирает, попадает в DLQ, оттуда обратно)

Почему не Kafka: Нет встроенной поддержки отложенных сообщений.

6. Надёжная доставка (at-least-once)

Вам нужно гарантировать, что сообщение не потеряется.

Пример: Платёжные транзакции, заказы, критичные бизнес-события.

Почему RabbitMQ:

Механизмы надёжности:
  - Publisher confirms (подтверждение от брокера)
  - Consumer acks (подтверждение от потребителя)
  - Persistent messages (сообщения на диске)
  - Durable queues (очереди сохраняются при перезапуске)
  - Quorum queues (репликация на несколько узлов)

Почему не Kafka: Kafka тоже надёжна, но для очереди задач (удаление после прочтения) RabbitMQ естественнее.

7. Интеграция со старыми системами

Нужно подключаться к системам с разными протоколами.

Пример: Старая система говорит на AMQP, новая — на MQTT, третья — на STOMP.

Почему RabbitMQ:

Поддерживаемые протоколы:
  - AMQP 0-9-1 (родной)
  - AMQP 1.0 (через плагин)
  - MQTT (IoT)
  - STOMP
  - HTTP (REST)

Признаки того, что RabbitMQ — плохой выбор

1. Нужно хранить историю и перечитывать (Replay)

Вам нужно иметь возможность перечитать сообщения, которые были отправлены неделю назад.

Почему плохо: RabbitMQ удаляет сообщения после подтверждения. Нет встроенной истории.

Решение: Kafka.

2. Очень высокая нагрузка (> 100 000 сообщений/сек)

У вас миллионы сообщений в секунду.

Почему плохо: RabbitMQ справляется с десятками тысяч, но для миллионов нужна Kafka.

Сравнение:

3. Строгий порядок сообщений в масштабе всей системы

Порядок должен быть глобальным, не только в рамках одной очереди.

Почему плохо: RabbitMQ гарантирует порядок внутри очереди, но не между очередями. Для глобального порядка нужна одна очередь (убивает масштабирование).

Решение: Kafka с одной партицией (тоже не масштабируется) или пересмотр требований.

4. Потоковая обработка (Stream Processing)

Вам нужно агрегировать, фильтровать, соединять потоки в реальном времени.

Пример: Подсчёт количества кликов по окнам в 5 минут.

Почему плохо: У RabbitMQ нет встроенных инструментов для потоковой обработки.

Решение: Kafka + Kafka Streams, Flink, Spark Streaming.

5. Маленькая нагрузка, но нужна простота

У вас несколько сообщений в день. RabbitMQ избыточен.

Решение: PostgreSQL с таблицей-очередью, Redis List.

RabbitMQ vs Kafka

Практические сценарии

Сценарий 1: Обработка заказов в интернет-магазине

Требования:
  - 1000 заказов в час
  - Заказы распределяются между 5 воркерами
  - Приоритет: VIP-заказы обрабатываются быстрее
  - Заказ не должен потеряться
  - При ошибке — повтор через 5 минут

Выбор: RabbitMQ

Почему:
  - Классическая очередь задач
  - Приоритеты
  - Подтверждения (ack)
  - Отложенные сообщения (retry)

Сценарий 2: Система логирования

Требования:
  - 100 000 сообщений/сек
  - Логи нужно хранить 30 дней
  - Несколько систем читают логи (ELK, аналитика)
  - Можно перечитать историю

Выбор: Kafka

Почему:
  - Высокая нагрузка
  - Хранение истории
  - Replay

Сценарий 3: Маршрутизация событий

Требования:
  - Событие "пользователь создан"
  - Должно идти в CRM, биллинг, маркетинг
  - Но: маркетингу только если пользователь согласился на рассылку
  - CRM — всегда
  - Биллинг — всегда

Выбор: RabbitMQ

Почему:
  - Topic exchange для рассылки
  - Headers exchange для фильтрации по подписке

Сценарий 4: RPC между микросервисами

Требования:
  - Сервис A вызывает сервис B
  - Ждёт ответа
  - Синхронное взаимодействие через брокер

Выбор: RabbitMQ

Почему:
  - Нативная поддержка RPC (reply_to, correlation_id)

RabbitMQ vs Другие брокеры

Выбор между RabbitMQ и Kafka

Вопросы для принятия решения:

1. Нужно ли хранить историю и перечитывать сообщения?
   - Да → Kafka
   - Нет → RabbitMQ

2. Какая нагрузка?
   - < 50 000 сообщений/сек → RabbitMQ
   - > 100 000 сообщений/сек → Kafka

3. Нужна ли сложная маршрутизация (topic, headers, фильтрация)?
   - Да → RabbitMQ
   - Нет → Kafka

4. Нужны ли приоритеты, отложенные сообщения, RPC?
   - Да → RabbitMQ
   - Нет → Kafka

5. Команда знает RabbitMQ или Kafka?
   - Знакомый инструмент → предпочтительнее

Распространённые ошибки

Ошибка 1: RabbitMQ для high-load

Пытаются использовать RabbitMQ для миллионов сообщений в секунду.

Решение: Kafka.

Ошибка 2: RabbitMQ как хранилище

Думают, что RabbitMQ можно использовать как базу данных. Сообщения удаляются.

Решение: Kafka или БД.

Ошибка 3: Игнорирование подтверждений

Не используют publisher confirms и consumer acks. Сообщения теряются.

Решение: Всегда использовать подтверждения для критичных данных.

Ошибка 4: Одна очередь на всё

Все типы сообщений в одной очереди. Трудно масштабировать, приоритеты не работают.

Решение: Разные очереди под разные типы задач.

Ошибка 5: Нет мониторинга

Очереди растут, никто не знает.

Решение: Мониторинг глубины очередей, алерты.

Резюме

1. RabbitMQ — для очередей задач, сложной маршрутизации, RPC, приоритетов, отложенных сообщений. Это классический брокер, который удаляет сообщения после прочтения.

2. Ключевые сценарии: распределение задач, маршрутизация по содержимому, publish-subscribe, RPC, отложенные задачи, приоритеты.

3. Не подходит для: хранения истории (replay), очень высоких нагрузок (>100 000/сек), потоковой обработки.

4. RabbitMQ vs Kafka: RabbitMQ — для очередей, Kafka — для потоков. Разные инструменты, разные задачи.

5. RabbitMQ vs SQS: SQS — управляемый, проще, но привязка к AWS. RabbitMQ — больше возможностей, но нужно администрировать.