Брокеры сообщений 2025: Kafka vs Pulsar vs RabbitMQ vs NATS + JetStream vs Redis Streams — когда что выбирать

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

Брокер сообщений — это архитектурный паттерн и специальное ПО, которое принимает сообщения от разных компонентов системы и потом распределяет их по адресатам. Брокер также отвечает за надёжность доставки и сохранность сообщений в случае сбоев.

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

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

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

Перед сравнением брокеров давайте разберём их характеристики. Их смысл очень важен для понимания темы.

Пропускная способность (throughput) — количество сообщений, которое брокер может обрабатывать в секунду.

Нужно понимать, что пропускная способность в статье теоретическая и была получена по сути в «вакуумных», синтетических условиях. И всё равно теоретические показатели пропускной способности позволяют оценить разницу между брокерами вполне достоверно.

Задержка (latency) — время от отправки сообщения до получения и обработки потребителем.

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

Гарантии доставки (delivery guarantees) — определяют что произойдёт с сообщением при сетевых ошибках, падении отправителя, получателя или самого брокера: будет ли оно потеряно, продублировано или доставлено строго один раз. Соответственно, различают гарантии «at most once», «at least once», «exactly once».

Репликация (replication) — механизм, который позволяет для надёжности хранить сообщения/данные в нескольких местах. Все брокеры так или иначе поддерживают репликацию, в статье указаны способы или принципы её реализации.

Сложность эксплуатации (operational difficulty) — относительная оценка того, насколько сложно внедрить и поддерживать брокер на проекте.

Ресурсы — вычислительные ресурсы, необходимые для работы брокера. В этой статье указаны ресурсы для одного простейшего и минимального production-узла с одним брокером.

Количество ресурсов для брокеров может значительно отличаться в зависимости от требований и размера проектов. Сначала мы обсудим базовые характеристики, реальные production-системы могут использовать значительно больше ресурсов.

RabbitMQ

RabbitMQ — самый старый из рассматриваемых, но до сих пор популярный программный брокер с поддержкой протокола AMQP (и не только, конечно). Изначально проект был задуман как масштабируемый брокер сообщений с поддержкой таких функций, как очереди сообщений, маршрутизация и долговременное хранение. Со временем клиентские библиотеки стали поддерживать конкурентность, а производительность повысилась. Позже апгрейд получили и очереди. Новые функции, такие как, например, quorum queues, были добавлены для обеспечения высокой доступности и сохранности данных за счёт репликации, основанной на алгоритме консенсуса Raft.

Характеристики:

Пропускная способность: 50 000–100 000.

Задержка: 5–20 мс.

Гарантии доставки: «at least once».

Репликация: quorum queues (Raft).

Сложность эксплуатации: средняя.

Ресурсы: 4 ядра CPU, 4 Гб RAM, 4-8 Гб SSD, не разворачивать на одном сервере с сервисами, которые активно используют сетевой ввод/вывод.

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

Kafka

Apache Kafka остаётся безусловным лидером для высоконагруженных сценариев стриминга событий и сейчас, по факту, промышленный стандарт. Пропускная способность — 500 000–1 000 000+ сообщений в секунду. Kafka доминирует в смысле горизонтального масштабирования, пропускной способности, репликации и отказоустойчивости.

Характеристики:

Пропускная способность: 500 000–1 000 000+ сообщений в секунду.

Задержка: 10-50 мс.

Гарантии доставки: «at least once», «exactly once».

Репликация: configurable replication factor (ISR).

Сложность эксплуатации: высокая.

Ресурсы: 4 ядра CPU, 4 Гб RAM, 8 Гб SSD.

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

Redis Streams

Redis Streams не вполне можно назвать брокером. По-хорошему, это структура данных, которая появилась в Redis 5.0. На её базе можно строить брокеры сообщений и это прекрасный выбор для систем, которые уже используют Redis как кэш и/или базу данных.

Характеристики:

Пропускная способность: 100 000–500 000 сообщений в секунду.

Задержка: 1-10 мс.

Гарантии доставки: «at least once».

Репликация: Redis Cluster, Master-Slave.

Сложность эксплуатации: низкая.

Ресурсы: 4 ядра CPU, 8 Гб RAM, 8 Гб SSD.

Redis Streams подойдёт в первую очередь для систем, в которых уже есть Redis. Это оптимальный выбор для проектов, в которых нужна высокая производительность (за счёт in-memory операций) в реальном времени с относительно небольшим объёмом данных и нет требований к высокой пропускной способности.

NATS + JetStream

NATS зарекомендовал себя как легковесная, масштабируемая облачно-ориентированная система обмена сообщениями. Его как раз и проектировали для облачных сред и IoT-систем с большим количеством подключений. JetStream расширяет возможности базового NATS: добавляет сохранность сообщений и «exactly once» гарантию доставки. NATS набирает популярность и в последние годы активно завоёвывает рынок.

Характеристики:

Пропускная способность: 200 000–400 000 сообщений в секунду.

Задержка: 1-5 мс.

Гарантии доставки: «at most once», «at least once», «exactly once» (с JetStream).

Репликация: R3 clustering (Raft).

Сложность эксплуатации: низкая.

Ресурсы: 2 ядра CPU, 4 Гб RAM, 4 Гб SSD.

IoT-проекты с большим количеством элементов, облачные среды, высокая скорость работы в реальном времени, простота применения — если это факторы, которые важны, NATS — то, что нужно.

Pulsar

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

Характеристики:

Пропускная способность: 1 000 000–2 600 000 сообщений в секунду.

Задержка: 5–20 мс.

Гарантии доставки: «at most once», «at least once», «exactly once».

Репликация: георепликация, слои хранилищ данных.

Сложность эксплуатации: высокая.

Ресурсы: 4 ядра CPU, 4 Гб RAM, 8 Гб SSD.

Pulsar подойдёт для систем, которые обрабатывают большие объёмы данных и при этом требуют универсальности очередей. Георепликация и высокая масштабируемость также делают его привлекательным выбором для определённых сценариев.

Сравнение характеристик брокеров сообщений

Куда же без краткой и наглядной таблицы. Напомню, что реальные характеристики могут значительно отличаться из-за настроек, условий и других факторов.

Как выбрать брокер сообщений и сколько стоит его поддерживать?

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

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

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

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

Давайте начнём с серверов. Я уже говорил, что мы попробуем посмотреть на цифры, которые могут быть на реальных проектах. В таблице ниже ресурсы, которые могут требовать брокеры сообщений. Я не буду вдаваться в подробности сценариев, скажу только, что в каждой категории проектов сценарий одинаковый и можно примерно сравнить порядок ресурсов, который могут потреблять разные брокеры. При этом нужно не забывать, что закладывается запас по ресурсам порядка 30% для пиковых нагрузок, внезапной необходимости масштабирования и других непредвиденных ситуаций.

Для базового уровня надёжности разворачивается хотя бы 2-3 экземпляра брокера. Если растут нагрузки, размер сообщений, требования к длительности их хранения, то систему пора масштабировать, а вместе с этим вырастет и объём потребляемых ресурсов.

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

Давайте для примера попробуем рассчитать расходы на оборудование для самого простого сценария из таблицы у Kafka.

Для простоты я просто выберу VDS у одного из популярных провайдеров. Конфигурация одного VDS с характеристиками «8 ядер, 32 Гб RAM, 20 Гб SSD» обойдётся порядка 10 тысяч рублей в месяц. Нам нужно три, соответственно, получится 30 тысяч в месяц. Это очень поверхностный рассчёт, но схема в целом всегда такая.

VDS я выбираю просто для простоты и наглядности рассчёта. Вариантов аренды или покупки вычислительных мощностей много: облако, bare metal, в конце концов свои сервера on-premise. У них тоже есть свои плюсы и минусы, но это не предмет данной статьи.

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

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

Итоги: выбирайте инструмент под задачу

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

В этой статье мы, конечно, не смогли охватить все характеристики и нюансы брокеров сообщений. Изучать их, читать документацию, разворачивать и настраивать придётся уже вам. Надеюсь, что эта статья помогла вам немного разобраться в том, что такое брокеры, какие у них есть характеристики и как подступиться к выбору и оценке подходящего именно для вас.

Если вас заинтересовала какая-то тема, которая связана со статьёй — пишите в комментариях.