Вы когда-нибудь заказывали пиццу в большом ресторане? Вы делаете заказ официанту, он передаёт его на кухню. Повара готовят, передают готовую пиццу обратно. Всё синхронно и просто. Но что, если заказов сотни? Официанты начнут путаться, повара — работать в хаосе. Тогда ресторан внедряет систему: заказы пишутся на бумажках и крепятся на вращающуюся стойку. Каждый повар берёт заказ, готовит и крепит бумажку готового блюда на другую стойку. Официант забирает, когда свободен.
Это и есть брокер сообщений. Он позволяет разным частям системы общаться асинхронно, не зная друг о друге, и выдерживать пиковые нагрузки.
В 2026 году выбор брокера сообщений — важное архитектурное решение. Есть классические очереди (RabbitMQ), есть лог-ориентированные системы для потоковой обработки (Kafka), есть лёгкие и быстрые решения для микросервисов (NATS) и современные переосмысления (Redpanda). Давайте разбираться.
Часть 1: Очереди vs Логи — в чём разница?
Все брокеры делятся на две большие группы.
Модель очереди (Queue)
Сообщение достаётся одному потребителю и удаляется после обработки. Если потребитель упал, сообщение возвращается в очередь. Пример: RabbitMQ, Amazon SQS, ActiveMQ.
Подходит для распределения задач между рабочими экземплями (workers). Сообщение живёт недолго и не перечитывается.
Модель лога (Log)
Сообщения хранятся последовательно и могут быть прочитаны многократно разными потребителями. Каждый потребитель помнит свою позицию (offset). Пример: Apache Kafka, Redpanda, AWS Kinesis.
Подходит для потоковой обработки событий, воспроизведения истории, интеграции многих систем.
Часть 2: Навигатор по брокерам 2026
RabbitMQ (Классическая очередь)
Философия: умная маршрутизация, гибкие очереди, поддержка сложных топологий (direct, topic, fanout, headers). Язык: Erlang.
Плюсы:
- Богатые возможности маршрутизации.
- Прост в настройке и использовании.
- Поддерживает множество протоколов (AMQP 0-9-1, MQTT, STOMP).
- Есть плагины и управление через веб-интерфейс.
Минусы:
- Пропускная способность ниже, чем у Kafka (тысячи сообщений/с против сотен тысяч).
- Хранение сообщений на диске менее эффективно.
- Нет гарантии глобального порядка сообщений.
Идеален для: Классических очередей задач, RPC-вызовов, интеграции приложений, когда нужна сложная маршрутизация.
Apache Kafka (Event Streaming)
Философия: распределённый лог событий, устойчивый к сбоям, с бесконечным хранением. Язык: Scala/Java.
Плюсы:
- Огромная пропускная способность (миллионы сообщений/с).
- Сохраняет события долго (дни, недели, годы).
- Гарантирует порядок сообщений в партиции.
- Экосистема: Kafka Streams, ksqlDB, Connect.
Минусы:
- Сложность настройки и администрирования (ZooKeeper, позже KRaft).
- Задержки (latency) выше, чем у RabbitMQ/NATS (миллисекунды против микросекунд).
- Не предназначена для очередей с удалением после чтения (хотя можно эмулировать).
Идеален для: Потоковой обработки событий, аналитики, CDC (Change Data Capture), микросервисов с воспроизведением истории.
NATS (Лёгкий и быстрый)
Философия: простота, скорость, надёжность. «Транспорт для облака». Язык: Go.
Плюсы:
- Чрезвычайно низкие задержки (микросекунды).
- Простой протокол и конфигурация.
- Поддержка JetStream (персистентное хранение, очереди, ключ-значение).
- Встроенная поддержка RPC и request-reply.
- Очень лёгкий (бинарник ~20 МБ).
Минусы:
- Меньше функциональности маршрутизации, чем у RabbitMQ.
- Сообщество меньше, чем у Kafka и RabbitMQ.
- Инструменты мониторинга слабее.
Идеален для: Внутренней коммуникации микросервисов, IoT, real-time приложений, где критична задержка.
Redpanda (Kafka-совместимый, но на C++)
Философия: «Kafka без JVM, с упрощённым администрированием». Язык: C++ (с использованием Seastar framework).
Плюсы:
- Полная совместимость с API Kafka (можно использовать существующие клиенты и инструменты).
- Выше производительность (нет GC, эффективное использование памяти).
- Проще настройка: не нужен ZooKeeper/KRaft, один бинарник.
- Встроенный веб-интерфейс для управления.
Минусы:
- Моложе экосистема, чем у Kafka.
- Меньше готовых коннекторов.
- Проприетарная лицензия на некоторые enterprise-фичи.
Идеален для: Проектов, которые хотят использовать Kafka API, но не хотят возиться с JVM и ZooKeeper. Для высоконагруженных сценариев.
Часть 3: Сравнительная карта
Модель обмена
- RabbitMQ: очереди + обменники.
- Kafka: лог + партиции.
- NATS: publish/subscribe + очереди (JetStream).
- Redpanda: лог + партиции (Kafka API).
Хранение сообщений
- RabbitMQ: до подтверждения или ограниченный TTL.
- Kafka: длительное, по времени или размеру.
- NATS: без JetStream — только в памяти; с JetStream — на диске.
- Redpanda: на диске, как у Kafka.
Порядок сообщений
- RabbitMQ: глобально не гарантируется (кроме отдельных очередей).
- Kafka: внутри партиции.
- NATS: в JetStream можно гарантировать на уровне потока.
- Redpanda: внутри партиции.
Задержки (latency)
- RabbitMQ: миллисекунды.
- Kafka: миллисекунды (часто выше, чем у RabbitMQ).
- NATS: микросекунды (самый быстрый).
- Redpanda: как у Kafka, чуть лучше за счёт C++.
Сложность администрирования
- RabbitMQ: средняя.
- Kafka: высокая.
- NATS: низкая.
- Redpanda: средняя (ниже, чем у Kafka).
Часть 4: Карта выбора
Какой у вас сценарий?
- Распределение задач между воркерами (один экземпляр обрабатывает одно сообщение) → RabbitMQ или NATS JetStream.
- Потоковая обработка событий, аналитика, replay истории → Kafka или Redpanda.
- Внутренний RPC между микросервисами с минимальной задержкой → NATS.
Нужна ли долговременная история событий?
- Да → Kafka/Redpanda.
- Нет → RabbitMQ или NATS в памяти.
Какой у вас опыт и ресурсы на поддержку?
- Есть сильная DevOps команда, готовые администрировать Kafka → берите Kafka.
- Хотим что-то простое, без Zookeeper, но с Kafka API → Redpanda.
- Хотим совсем простой брокер, почти не требующий забот → NATS или RabbitMQ.
Какая пропускная способность нужна?
- Очень высокая (миллионы сообщений в секунду) → Kafka, Redpanda.
- Средняя (десятки тысяч) → RabbitMQ или NATS.
Часть 5: Тренды 2026
- Упрощение Kafka: KRaft (без ZooKeeper) делает Kafka легче в настройке. Redpanda ещё проще.
- NATS с JetStream становится серьёзным конкурентом для RabbitMQ и даже для лёгких сценариев Kafka.
- WebAssembly в брокерах — фильтрация и трансформация сообщений на Wasm без перезапуска.
- Брокеры как сервис (managed) вытесняют self-hosted для небольших проектов (Confluent Cloud, Redpanda Cloud, NATS Cloud).
- Интеграция с векторными базами для AI-пайплайнов — брокеры становятся транспортом для эмбеддингов.
В 2026 году нет одного лучшего брокера. Выбирайте инструмент под конкретную задачу:
- RabbitMQ — для сложной маршрутизации и классических очередей.
- Kafka — для потоковой обработки и истории событий (если готовы к сложности).
- Redpanda — для Kafka-совместимости без головной боли.
- NATS — для скорости и лёгкости, особенно в микросервисах и IoT.
Начинайте с простого (NATS или RabbitMQ). Если вырастете до необходимости в истории событий и высокой пропускной способности — переходите на Kafka/Redpanda. А иногда можно использовать два брокера: RabbitMQ для очередей задач и NATS для real-time коммуникации.
А вы какой брокер используете в своих проектах?
Поделитесь опытом в комментариях:
- Какой брокер у вас в продакшене и почему выбрали именно его?
- Сталкивались ли с проблемами производительности или масштабирования?
- Пробовали ли Redpanda как альтернативу Kafka? Какие впечатления?
Ваш опыт поможет другим не ошибиться с выбором.
Подписывайтесь на «Навигатор по миру IT». Следующая статья — Современные подходы к кэшированию 2026: Redis, Memcached, Hazelcast и новое поколение. Когда кэш нужен, а когда он только мешает.