Перейти к содержимому

Другие брокеры

Ключевые альтернативы Kafka и RabbitMQ: ActiveMQ (классика для Java/JMS, но устаревает), NATS (высокая скорость и низкая задержка для микросервисов, с JetStream — персистентность), Redis Pub/Sub (простота, но без гарантий и персистентности), Google Pub/Sub (управляемый сервис для GCP), ZeroMQ (библиотека без брокера для встраиваемых систем) и Apache Pulsar (современный гибрид Kafka и RabbitMQ с geo-репликацией).

Введение: Не только Kafka и RabbitMQ

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

Каждый брокер создавался под определённые задачи. ActiveMQ — для Java-экосистемы и старых корпоративных систем. NATS — для сверхбыстрой передачи сообщений в микросервисах. Redis Pub/Sub — для простоты, когда потеря данных допустима. Google Pub/Sub — для глобальных масштабов в облаке GCP. ZeroMQ — для встраиваемых систем без отдельного сервера.

Для системного аналитика знание альтернатив расширяет инструментарий. Иногда Kafka избыточна, RabbitMQ не подходит по производительности, а облачный брокер решает проблему отсутствия инфраструктурной команды.

Обзорная таблица

БрокерОсновная нишаМодельПроизводительностьСложностьУправление
ActiveMQJava, корпоративные системыОчередь + топикСредняяСредняяСамостоятельное
NATSМикросервисы, низкая задержкаPub-subОчень высокаяНизкаяСамостоятельное
Redis Pub/SubПростые сценарии, кешPub-subВысокаяОчень низкаяСамостоятельное
Google Pub/SubОблако GCP, глобальнаяPub-subВысокаяНизкаяУправляемый
ZeroMQВстраиваемые системыБиблиотекаОчень высокаяВысокаяНет
Apache PulsarПотоки + очередиОчередь + топик + журналВысокаяВысокаяСамостоятельное

ActiveMQ

Что это

ActiveMQ — это классический брокер сообщений на Java, реализующий протокол JMS (Java Message Service). Был очень популярен в 2000-х и начале 2010-х для корпоративных систем.

Архитектура

Особенности:
  - Написан на Java
  - Поддерживает JMS 1.1 и 2.0
  - Протоколы: OpenWire, AMQP, MQTT, STOMP, WebSocket
  - Персистентность: через файлы, JDBC (БД), Kahadb
  - Кластеризация: мастер-слейв, shared store

Когда использовать

Хорошо подходит:
  - Java-экосистема (Spring, JMS)
  - Корпоративные системы (банки, страховые)
  - Миграция со старых систем
  - Смешанные протоколы (AMQP, MQTT, STOMP)

Не подходит:
  - Высокая нагрузка (>50k msg/sec)
  - Современные микросервисы (NATS или Kafka лучше)

Преимущества и недостатки

ПреимуществаНедостатки
Зрелый, стабильныйУстаревшая архитектура
Поддержка JMSНизкая производительность
Много протоколовСложная кластеризация
Хорошая интеграция с JavaСообщество уменьшается

NATS

Что это

NATS — это высокопроизводительный, лёгкий брокер сообщений, созданный Cloud Foundry. Он спроектирован для простоты и скорости.

Архитектура

Особенности:
  - Написан на Go
  - Протокол: текстовый, очень простой
  - Модель: publish-subscribe
  - at-most-once доставка (по умолчанию)
  - at-least-once через NATS JetStream
  - Персистентность: через JetStream
  - Кластеризация: встроенная (RAFT)

Протокол NATS (пример)

# Публикация
PUB foo 5
Hello

# Подписка
SUB foo 1

# Сообщение
MSG foo 1 5
Hello

Когда использовать

Хорошо подходит:
  - Микросервисная архитектура
  - Высокая производительность (>100k msg/sec)
  - Низкая задержка (<1ms)
  - IoT, телеметрия
  - Облачные среды (Kubernetes)

Не подходит:
  - Сложная маршрутизация
  - Долгое хранение сообщений (без JetStream)

NATS JetStream

Расширение для персистентности:
  - at-least-once доставка
  - Хранение сообщений на диске
  - Replay
  - Dead Letter Queue
  - Exactly-once (в пределах потока)

Преимущества и недостатки

ПреимуществаНедостатки
Очень высокая скоростьПростая маршрутизация
Низкая задержкаat-most-once по умолчанию
ПростотаМеньше возможностей, чем у Kafka
Лёгкий (бинарник ~10МБ)Сообщество меньше
Встроенная кластеризация

Redis Pub/Sub

Что это

Redis Pub/Sub — это механизм публикации/подписки, встроенный в Redis. Он использует тот же сервер, что и кеш Redis.

Архитектура

Особенности:
  - Встроен в Redis
  - Протокол: RESP (Redis Serialization Protocol)
  - Модель: publish-subscribe (нет очередей)
  - Нет персистентности
  - Нет гарантий доставки
  - Нет подтверждений (ack)

Пример

# Подписка
SUBSCRIBE news

# Публикация
PUBLISH news "Hello, world!"

# Результат
1) "message"
2) "news"
3) "Hello, world!"

Когда использовать

Хорошо подходит:
  - Простые сценарии уведомлений
  - Чат (не критичный)
  - Логи, метрики (потеря допустима)
  - Вместе с Redis как кешем (единая инфраструктура)

Не подходит:
  - Критичные данные (нет гарантий)
  - Сообщения, которые нельзя терять
  - Долгое хранение

Преимущества и недостатки

ПреимуществаНедостатки
Очень простойНет персистентности
Высокая скоростьНет гарантий доставки
Часть Redis (единый стек)Нет подтверждений
Нулевая конфигурацияat-most-once только

Google Pub/Sub

Что это

Google Pub/Sub — это полностью управляемый облачный брокер сообщений от Google Cloud Platform (GCP).

Архитектура

Особенности:
  - Управляемый сервис (не нужно администрировать)
  - Модель: publish-subscribe (топики, подписки)
  - Гарантии: at-least-once
  - Персистентность: автоматическая
  - Глобальная доступность (мульти-регион)
  - Интеграция с GCP (Cloud Functions, Dataflow, BigQuery)

Ключевые концепции

Топик (Topic):
  - Категория сообщений

Подписка (Subscription):
  - Привязка подписчика к топику
  - Типы: pull (клиент забирает), push (сервер отправляет)

Обработка:
  - Подтверждения (ack)
  - Повторная доставка при отсутствии ack

Когда использовать

Хорошо подходит:
  - Проекты на Google Cloud
  - Нет команды для администрирования брокера
  - Глобальные приложения (мульти-регион)
  - Интеграция с GCP сервисами

Не подходит:
  - Не в GCP (дорогой трафик)
  - Высокая чувствительность к задержкам
  - Нужен полный контроль над инфраструктурой

Преимущества и недостатки

ПреимуществаНедостатки
Полностью управляемыйПривязка к GCP
Автоматическое масштабированиеДорогой трафик из других облаков
Глобальная доступностьМеньше возможностей, чем Kafka
Интеграция с GCPНе подходит для сверхнизких задержек
at-least-once + идемпотентность

ZeroMQ

Что это

ZeroMQ (ØMQ) — это не брокер, а библиотека для передачи сообщений. Встраивается в приложение, не требует отдельного сервера.

Архитектура

Особенности:
  - Библиотека (не сервер)
  - Нет брокера (peer-to-peer)
  - Паттерны: request-reply, publish-subscribe, push-pull
  - Протоколы: TCP, UDP, in-process, IPC
  - Нет персистентности (приложение само управляет)

Когда использовать

Хорошо подходит:
  - Встраиваемые системы (IoT, embedded)
  - Высокая производительность, низкая задержка
  - Нет возможности развернуть брокера
  - Простые топологии (небольшое количество узлов)

Не подходит:
  - Сложная маршрутизация
  - Персистентность
  - Мониторинг и управление

Преимущества и недостатки

ПреимуществаНедостатки
Очень высокая скоростьНет брокера (сложнее)
Низкая задержкаНет персистентности
Нет отдельного сервераНет мониторинга
Много паттерновСложная отладка
ЛегковесныйТолько для продвинутых

Apache Pulsar

Что это

Apache Pulsar — это современный брокер сообщений, который сочетает в себе возможности Kafka (логи) и RabbitMQ (очереди).

Архитектура

Особенности:
  - Двухуровневая архитектура: брокеры + bookies (хранение)
  - Модель: очереди + топики + журналы
  - Персистентность: через Apache BookKeeper
  - Гарантии: at-least-once, exactly-once
  - Geo-replication (мульти-регион)
  - Кластеризация: встроенная

Уровни хранения

Broker (без состояния):
  - Обработка запросов
  - Маршрутизация

BookKeeper (хранение):
  - Распределённое, персистентное
  - Репликация
  - Может масштабироваться независимо

Когда использовать

Хорошо подходит:
  - Сочетание потоков и очередей
  - Geo-распределённые системы
  - Высокая надёжность (репликация)
  - Миграция с Kafka/RabbitMQ

Не подходит:
  - Маленькие проекты (сложно)
  - Нет команды для администрирования

Преимущества и недостатки

ПреимуществаНедостатки
Kafka + RabbitMQ в одномСложность
Geo-репликацияМаленькое сообщество
Отдельное масштабирование храненияМеньше инструментов, чем у Kafka
ПерсистентностьТребует обучения
Exactly-once

Выбор брокера

Вопросы для принятия решения:

1. Где будет работать система?
   - В облаке (AWS) → SQS/SNS
   - В облаке (GCP) → Google Pub/Sub
   - В своём дата-центре → Kafka / RabbitMQ / NATS

2. Есть ли команда для администрирования?
   - Да → Kafka, RabbitMQ, NATS
   - Нет → управляемый сервис (SQS, Google Pub/Sub)

3. Какая нагрузка?
   - >100k msg/sec → Kafka, NATS
   - <50k msg/sec → RabbitMQ, ActiveMQ
   - Небольшая → Redis Pub/Sub

4. Нужна ли история (replay)?
   - Да → Kafka, Pulsar, NATS JetStream
   - Нет → RabbitMQ, ActiveMQ

5. Какая задержка?
   - <1ms → NATS, ZeroMQ
   - 1-10ms → Kafka, RabbitMQ
   - >10ms → ActiveMQ

6. Нужна ли сложная маршрутизация?
   - Да → RabbitMQ
   - Нет → Kafka, NATS

Распространённые ошибки

Ошибка 1: NATS для задач (не для pub-sub)

NATS — pub-sub, не очередь задач. Нет competing consumers (без JetStream).

Решение: NATS JetStream для очередей.

Ошибка 2: Redis Pub/Sub для критичных данных

Нет персистентности, нет гарантий. Сообщения теряются при перезапуске Redis.

Решение: RabbitMQ или Kafka.

Ошибка 3: ActiveMQ для high-load

ActiveMQ не справляется с нагрузкой >50k msg/sec.

Решение: Kafka или NATS.

Ошибка 4: Google Pub/Sub вне GCP

Трафик из AWS в GCP дорогой, задержки высокие.

Решение: Использовать брокера в том же облаке.

Ошибка 5: ZeroMQ без опыта

ZeroMQ сложен в отладке. Легко допустить ошибки в конфигурации.

Решение: Если нужен брокер — взять NATS или RabbitMQ.

Резюме

  1. ActiveMQ — классика для Java/JMS. Устаревает, но жив в корпоративных системах.

  2. NATS — скорость и простота. Для микросервисов, IoT, высоких нагрузок. NATS JetStream добавляет персистентность.

  3. Redis Pub/Sub — простота и скорость. Для неважных данных, где потеря допустима.

  4. Google Pub/Sub — управляемый брокер для GCP. Глобальный, масштабируемый.

  5. ZeroMQ — библиотека без брокера. Для встраиваемых систем, экстремальной производительности.

  6. Apache Pulsar — современный брокер, сочетающий Kafka и RabbitMQ. Geo-распределённый.

Проверка знаний

Вопрос 1 из 4
Что подчёркивается в теме 'Другие брокеры'?
Когда особенно уместны управляемые облачные брокеры вроде SQS/SNS или Google Pub/Sub?
Какой критерий важен при выборе альтернативного брокера?
Почему опасно выбирать брокер по принципу 'знакомый инструмент'?

Вопросы, где были ошибки