Redis, RabbitMQ или Kafka: какую очередь выбрать

Redis, RabbitMQ и Kafka могут передать задачу из одного сервиса в другой, но цена неправильного выбора проявляется по-разному: у RabbitMQ растёт очередь необработанных сообщений, у Redis теряются данные при неверной настройке, а у Kafka усложняются эксплуатация и модель потребления. Ниже — практическое сравнение для систем на Redis 7.x, RabbitMQ 4.x и Apache Kafka 3.x: что выбрать для фоновых задач, интеграций, событий и потоков данных.

Сначала определите, что именно вы называете очередью

Очередь заданий хранит работу до тех пор, пока конкретный обработчик не выполнит её. Например, сервис положил в очередь отправку письма, а воркер забрал задачу, отправил письмо и подтвердил обработку.

Шина событий решает другую задачу. Она сохраняет факт события, например OrderPaid, чтобы его могли независимо прочитать биллинг, аналитика и сервис уведомлений. Одно событие может понадобиться нескольким потребителям, причём не обязательно одновременно.

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

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

Термин: consumer group — группа потребителей, совместно читающих сообщения. Внутри одной группы сообщение обычно обрабатывает один участник, а разные группы получают собственные копии логики потребления.

Три подхода и их цена

Redis Streams: быстрый старт и минимум инфраструктуры

Redis 7.x можно использовать как брокер через Streams. Запись попадает в поток, а consumer groups распределяют сообщения между обработчиками. Это удобно, когда Redis уже нужен приложению для кеша, блокировок или счётчиков и вы не хотите добавлять отдельный кластер.

Цена простоты — более узкий набор брокерских гарантий и больше ответственности на приложении. Нужно продумать подтверждение обработки, повторную доставку зависших сообщений, очистку старых записей и поведение при переполнении памяти. Redis Streams не превращает Redis в полноценную замену Kafka для долгого журнала событий.

Redis подходит для фоновых задач с небольшой или умеренной нагрузкой, задержек в миллисекундах и сценариев, где потеря сообщения допустима только при явно выбранной настройке. Для критичных платежных операций одной фразы «сообщение записалось в Redis» недостаточно: нужны тесты отказа, политика персистентности и понятная стратегия повторов.

RabbitMQ: очередь задач с подтверждениями и маршрутизацией

RabbitMQ 4.x строится вокруг exchange, очередей и routing key. Продюсер отправляет сообщение в exchange, тот маршрутизирует его в одну или несколько очередей, а consumer подтверждает успешную обработку. Такой слой хорошо подходит для рабочих заданий, где важно не потерять сообщение из-за временно недоступного обработчика.

RabbitMQ даёт привычные для очереди механизмы: acknowledgements, повторную доставку, dead-letter-маршрутизацию и ограничение числа сообщений, выданных потребителю без подтверждения. За это приходится платить настройкой топологии, контролем заполнения очередей и вниманием к порядку сообщений: параллельные consumers могут обработать их не в исходной последовательности.

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

Kafka: журнал событий и независимое чтение

Apache Kafka 3.x хранит записи в топиках, разбитых на partition. Потребитель сохраняет позицию чтения, offset, поэтому группа может перечитать данные или подключить новый сервис к истории. Это меняет архитектуру: продюсер публикует событие, а потребители сами решают, когда и сколько раз его обработать.

Главное ограничение Kafka — порядок гарантируется только внутри одной partition. Если ключом выбрать идентификатор заказа, события одного заказа можно направить в одну partition, но глобального порядка для всех заказов не будет. Число partition влияет на параллелизм и не меняется без архитектурных последствий для распределения нагрузки.

Kafka оправдана для больших потоков событий, аналитики, CDC, аудита и нескольких независимых потребителей. Она требует больше дисциплины: нужно управлять retention, lag, размером сообщений, схемами событий и ёмкостью дисков. Поднять Kafka ради пяти фоновых задач — обычно значит купить эксплуатационную сложность раньше, чем она понадобилась.

Сравнение по критическим критериям

Как выбрать без спора о вкусах

1. Выберите Redis Streams, если Redis уже работает в проекте, сообщения короткоживущие, а команда готова сама контролировать подтверждения, повторы и очистку. Не смешивайте требования кеша и очереди без проверки политики persistence и лимита памяти.
2. Выберите RabbitMQ, если каждое сообщение — это отдельная работа, которую должен выполнить один обработчик. Особенно полезны явные подтверждения, маршрутизация по типам задач, dead-letter-очереди и ограничение скорости потребителей.
3. Выберите Kafka, если событие должны независимо читать несколько систем, историю нужно хранить и перечитывать, а поток будет расти. До внедрения посчитайте количество partition, объём записи в сутки и срок хранения, иначе кластер начнёт упираться в диск раньше, чем станет понятна его ценность.

Критерий, который часто экономит месяцы

Спросите: что должен сделать потребитель после перезапуска? Если ответ — «продолжить с необработанной задачи», смотрите на RabbitMQ или Redis Streams. Если ответ — «прочитать события за последние семь дней заново и построить новую проекцию», Kafka подходит естественнее.

Нужна доставка «ровно один раз»? Не принимайте это требование на веру. В распределённой системе обработчик может завершиться после записи результата, но до подтверждения сообщения, поэтому повторная доставка возможна. Проектируйте обработчики идемпотентными: повтор одного и того же события не должен дважды списывать деньги или создавать заказ.

Что ломается на практике

Redis Streams

• Команда удаляет старые записи слишком агрессивно и оставляет consumer group с потерянными сообщениями.
• Зависшие записи остаются без контроля, потому что никто не забирает сообщения, выданные упавшему consumer.
• Redis заполняет память, а приложение замечает проблему только после ошибок записи.

RabbitMQ

• Consumer подтверждает сообщение до завершения бизнес-операции, и при падении задача уже не возвращается в очередь.
• Повторная доставка создаёт дубликаты, если обработчик не защищён идемпотентным ключом.
• Очередь растёт бесконечно: нет метрики длины очереди, возраста старейшего сообщения и лимита нагрузки.

Kafka

• События распределяются по случайному ключу, поэтому порядок для одного заказа теряется.
• Offset фиксируется раньше записи результата, и сбой между этими действиями приводит к пропущенной обработке.
• Новый consumer отстаёт от потока: растёт consumer lag, но команда смотрит только на доступность брокеров.

Как сравнивать до внедрения

Не ограничивайтесь тестом «кто обработал больше сообщений в секунду». Он не отвечает на главный вопрос — что случится после падения consumer, брокера или сети.

Для каждого кандидата проведите одинаковый сценарий: отправьте сообщения, остановите обработчик после получения части данных, восстановите его и проверьте число результатов, дубликаты и время восстановления. Отдельно измерьте размер сообщения, количество параллельных consumers, долю повторов и рост хранилища за сутки. Публичных цифр чужого бенчмарка недостаточно: результат зависит от дисков, сетевой задержки, настроек подтверждения и характера нагрузки.

Минимальный набор метрик для продакшена:

• возраст самого старого необработанного сообщения;
• длина очереди или consumer lag;
• число повторных доставок и сообщений в dead-letter;
• время обработки p95 и p99;
• объём занятого диска или памяти и скорость его роста.

Что делать дальше

Опишите одно сообщение: его размер, допустимую задержку, срок хранения, последствия дубликата и действие при падении обработчика. Затем проведите отказной тест на выбранном брокере и только после этого фиксируйте топологию, retention, лимиты и правила повторов. Для Redis отдельно прочитайте документацию по Streams и consumer groups, для RabbitMQ — по acknowledgements и dead lettering, для Kafka — по topics, partitions и consumer groups.