Очереди задач: RabbitMQ vs Redis Streams vs Yandex Message Queue

Очередь сообщений нужна, как только в проекте появляется хотя бы одна асинхронная задача, которая не должна блокировать HTTP-запрос: отправка email, генерация документа, обращение к внешнему API, обработка загруженного файла. На бумаге выбор простой, на практике у трёх популярных решений разные сильные стороны и разная цена эксплуатации. Расскажу о трёх, которые мы используем чаще всего в РФ-проектах в 2026.

RabbitMQ — рабочая лошадка с богатыми возможностями

Классический брокер сообщений с поддержкой AMQP 0.9.1 и AMQP 1.0. Версия 4.x стабильна, есть штатный quorum-queue (репликация для отказоустойчивости), поддержка streams для журнальных нагрузок.

Когда выбираем:

• Нужны разные топологии маршрутизации: direct, topic, fanout, headers. Например, одно событие должно пойти в три разных воркера, но обработчиков может быть динамическое число
• Нужны гарантии доставки уровня enterprise: ack/nack, dead-letter exchange, retry с экспоненциальной задержкой
• Команда уже знает AMQP — это базовый стек для Symfony, Spring и Django-RQ-альтернатив

Что больно:

• Деплой кластера на самостоятельный хостинг — требует понимания Erlang и Mnesia. Большая часть production-инцидентов в RabbitMQ происходит при разделении кластера (split brain), и лечится это руками
• На небольших объёмах (до 100 сообщений в секунду) бывает overkill — настройка занимает дольше, чем сама бизнес-логика
• Метрики и наблюдаемость требуют отдельной настройки (prometheus_rabbitmq_exporter), из коробки только web UI

Стоимость: бесплатный сам по себе. Размещение на VPS — от 1000 руб/мес. Управляемый RabbitMQ есть у Yandex Cloud (managed) и Selectel, в среднем 5-15 тыс. руб/мес за рабочий кластер из трёх узлов.

Redis Streams — простота и скорость, если уже есть Redis

Не отдельный продукт, а возможность Redis 5+ (стабильная с 6.x). Это упорядоченный лог записей, из которого читают группы потребителей. На вид похоже на Kafka в миниатюре.

Когда выбираем:

• В проекте уже есть Redis для кеша/сессий, добавлять отдельную инфраструктуру не хочется
• Нужно ОЧЕНЬ быстро — Redis Streams выдают сотни тысяч сообщений в секунду на одном узле
• Логика обработки относительно простая: воркер берёт сообщение, делает работу, подтверждает
• Нужна возможность «прочитать историю» — Streams хранят сообщения, пока не превысят лимит размера

Что больно:

• Нет встроенной топологии маршрутизации — если нужно «отправить одно событие пяти разным группам», это всё равно делается, но руками через несколько Streams и fan-out на клиенте
• Гарантии доставки — at-least-once. Идемпотентность ложится на воркер
• В кластерной Redis Streams распределяются по slots, и при scale-out иногда переезжают между узлами — клиент должен это обрабатывать
• Persistence — это AOF/RDB Redis, что не то же самое, что брокер «по дизайну». Если Redis упадёт по памяти, могут быть потери

Стоимость: бесплатный. Self-hosted Redis на 4GB VPS — около 1500 руб/мес. Managed Redis в Yandex Cloud — от 4000 руб/мес за минимальную конфигурацию с репликой.

Yandex Message Queue — managed SQS-совместимый сервис

Управляемая очередь в Yandex Cloud, API почти полностью совместимое с Amazon SQS. Серверов в управлении ноль, платим за число сообщений и трафик.

Когда выбираем:

• Не хочется управлять инфраструктурой вообще — нужна «очередь как услуга»
• Объёмы переменные: тысяча сообщений в день половину месяца, миллион в день оставшиеся дни — платим только за то, что использовали
• Команда уже работает с SQS на других проектах — миграция вопрос смены endpoint
• Нужна интеграция с другими сервисами Yandex Cloud: Functions, Triggers, Object Storage

Что больно:

• Топология ровно одна — FIFO или стандартная очередь. Если нужна маршрутизация по типу сообщения, делайте несколько очередей
• Задержка выше, чем у self-hosted решений: 20-100ms на операцию против 1-5ms у локального Redis. Для большинства задач это не критично, но если очередь — это hot path — заметите
• FIFO-очереди имеют лимит 300 сообщений в секунду на группу
• Привязка к Yandex Cloud — переезд на другое облако потребует переписать клиентский код, хотя SQS-совместимость снижает боль

Стоимость: 0,40 руб за 1000 запросов после первых 100 тыс. в месяц бесплатно. Для проекта с миллионом сообщений в месяц — около 400 руб/мес плюс трафик. Серверов содержать не нужно.

Сравнительная таблица в одном абзаце

Если очень коротко: RabbitMQ — когда нужна гибкая маршрутизация и enterprise-фичи, готовы платить за обслуживание; Redis Streams — когда Redis уже есть и хочется высокую скорость с минимальной инфраструктурой; Yandex MQ — когда не хочется управлять серверами и устраивает простая модель очереди.

Что выбрать под типичные сценарии

• Отправка email/SMS из веб-приложения — Yandex MQ или Redis Streams. Объёмы небольшие, требований к маршрутизации нет
• Обработка изображений после загрузки — Redis Streams (если уже есть Redis) или Yandex MQ + Yandex Functions для serverless обработки
• Событийная архитектура с несколькими микросервисами — RabbitMQ с topic exchange. Это его профильная задача
• Большие потоки данных (миллионы событий в день, аналитика) — ни одно из трёх. Смотрите на Kafka, Yandex Data Streams или ClickHouse напрямую
• Распределённые задачи с приоритетами — RabbitMQ с priority queue, либо несколько очередей в любом из решений

Что мы делаем по умолчанию

На новых проектах с PHP/Symfony — RabbitMQ, потому что Symfony Messenger из коробки с ним работает, и обвязка минимальная. На проектах с Python/Django — обычно Redis Streams через библиотеку rq или celery с Redis backend. Если клиент уже в Yandex Cloud и не хочет управлять инфраструктурой — Yandex MQ. Никаких религиозных предпочтений, выбираем под конкретный стек.

Что не делайте

• Не запускайте брокер на той же машине, что и веб-сервер, даже на старте. При нагрузке они конкурируют за CPU и память
• Не пишите свои очереди на базе таблицы в БД — это работает только до первого пика, а потом блокировки разваливают всё
• Не игнорируйте идемпотентность воркеров. Любая очередь рано или поздно доставит сообщение дважды, и если воркер не готов — будет двойная запись
• Не разворачивайте кластер RabbitMQ, если в команде нет человека, который понимает Erlang. Возьмите managed

Выбор очереди — это в первую очередь выбор операционной модели: сколько вы готовы тратить на эксплуатацию против сколько готовы платить провайдеру. Технически все три решения справятся с типовой задачей.