Kafka или RabbitMQ: какой брокер сообщений выбрать

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

Разберём, чем они отличаются по устройству и как выбрать.

Чем RabbitMQ отличается от Kafka по устройству?

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

Из этого следуют главные различия:

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

Когда выбирать RabbitMQ?

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

Типичные сценарии:

1. Фоновые задачи, которые ставит одно приложение, а выполняют воркеры на другом стеке.
2. Команды между сервисами: «списать платёж», «отправить уведомление», «сформировать документ».
3. Маршрутизация по типам: заказы из разных регионов — в разные очереди обработки.
4. Повторы с задержкой и очередь неудачных сообщений для ручного разбора.

Если очереди нужны внутри одного приложения, часто хватает Redis или базы данных — об этом в статье очереди задач в веб-приложении.

Когда выбирать Kafka?

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

Типичные сценарии:

• поток пользовательских событий для аналитики и рекомендаций;
• передача изменений из основной базы в другие системы — например, в аналитическое хранилище, о котором мы писали в статье ClickHouse для аналитики;
• журнал аудита, который нельзя терять и нужно хранить;
• обмен событиями между многими командами и сервисами в крупной системе.

Фото: Unsplash

Как сравнить их по ключевым критериям?

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

Критерий	RabbitMQ	Kafka
Модель	Очереди сообщений с подтверждением	Журнал событий с хранением
Что происходит после обработки	Сообщение удаляется	Событие остаётся до конца срока хранения
Несколько независимых потребителей	Через отдельные очереди	Нативно, через группы потребителей
Повторное чтение истории	Нет	Да, с любой позиции
Маршрутизация	Гибкая: ключи, шаблоны, заголовки	По темам и разделам
Пропускная способность	Высокая	Очень высокая
Сложность эксплуатации	Ниже	Выше, особенно без управляемого сервиса
Типичное применение	Задачи и команды	Потоки событий и данные

Схемы на пальцах

RabbitMQ:  заказ создан → обменник → очередь «письма»   → воркер писем (сообщение удалено)
                                   → очередь «склад»    → воркер склада (сообщение удалено)

Kafka:     тема «orders»: [e1][e2][e3][e4][e5] ...  хранится 7 дней
             ├─ группа «аналитика» читает с e1
             ├─ группа «поиск» дочитала до e4
             └─ новая группа «рекомендации» начинает с e1

Нужен ли брокер вообще?

Брокер нужен не каждому проекту: если у вас одно приложение и фоновые задачи внутри него, отдельный RabbitMQ или Kafka добавят эксплуатационные расходы без явной пользы. Брокер оправдан, когда появляется обмен между несколькими сервисами или поток событий, который нужен разным потребителям.

Признаки, что пора:

• несколько сервисов на разных стеках обмениваются задачами;
• одно событие должны получить несколько независимых систем;
• нужна гарантированная доставка с подтверждениями и повторами;
• объём событий перерос возможности Redis или базы данных.

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

Коротко

• RabbitMQ — брокер для доставки задач и команд с гибкой маршрутизацией; сообщение удаляется после обработки.
• Kafka — журнал событий с хранением и повторным чтением для многих потребителей.
• Для фоновых задач и команд между сервисами обычно хватает RabbitMQ, для потоков данных — Kafka.
• Внутри одного приложения часто достаточно Redis или базы данных без отдельного брокера.
• Управляемые облачные версии снимают большую часть сложности эксплуатации.