С какими брокерами сообщений работал

Опыт работы с брокерами сообщений

За 10+ лет коммерческой разработки на Go я работал с широким спектром брокеров сообщений (message brokers) и очередей задач (task queues), которые можно условно разделить на несколько категорий по их архитектуре и назначению.

Основные брокеры в production-проектах

Apache Kafka

Наиболее глубокий опыт у меня с Apache Kafka – распределённой потоковой платформой, которую я использовал для построения event-driven архитектур в микросервисных системах.

// Пример producer на Go с использованием sarama
producer, err := sarama.NewSyncProducer([]string{"kafka:9092"}, config)
if err != nil {
    log.Fatalf("Failed to start producer: %v", err)
}

msg := &sarama.ProducerMessage{
    Topic: "user-events",
    Value: sarama.StringEncoder(jsonData),
    Key:   sarama.StringEncoder(userID),
}

partition, offset, err := producer.SendMessage(msg)

Типовые use cases с Kafka:

• CDC (Change Data Capture) – отслеживание изменений в БД
• Аналитика в реальном времени – обработка clickstream
• Согласованность данных между микросервисами через event sourcing
• Логирование и аудит – централизованный сбор логов

RabbitMQ

RabbitMQ – классический AMQP-брокер, который я применял для RPC-коммуникации и распределения задач между сервисами.

// Подключение к RabbitMQ с использованием streadway/amqp
conn, err := amqp.Dial("amqp://guest:guest@rabbitmq:5672/")
ch, err := conn.Channel()
err = ch.ExchangeDeclare("logs", "direct", true, false, false, false, nil)

Особенности работы с RabbitMQ в Go:

• Использование непрерывных соединений (persistent connections) для снижения накладных расходов
• Реализация reconnect логики с экспоненциальной задержкой
• Работа с разными exchange типами (direct, topic, fanout, headers)
• Настройка dead letter exchanges для обработки неудачных сообщений

Redis как брокер

Redis часто использовался в качестве легковесного брокера через механизмы:

• Pub/Sub для реального времени
• Streams (с Redis 5.0+) для более надёжной доставки
• Lists с BRPOP для простых очередей задач

// Использование Redis Streams с go-redis
client := redis.NewClient(&redis.Options{Addr: "redis:6379"})
// Producer
err := client.XAdd(ctx, &redis.XAddArgs{
    Stream: "notifications",
    Values: map[string]interface{}{"user_id": 123, "type": "email"},
}).Err()

Дополнительные технологии

Amazon SQS/SNS

В облачных проектах активно использовал Amazon SQS (очереди) и SNS (нотификации):

• Standard queues для максимальной пропускной способности
• FIFO queues когда важна строгая последовательность
• Dead-letter queues для отладки проблемных сообщений
• SNS-to-SQS fanout для широковещательной рассылки

NATS/NATS Streaming (JetStream)

NATS применял для высокопроизводительных систем, где важна минимальная задержка:

• Core NATS для запрос-ответ паттернов
• NATS Streaming для персистентности (теперь JetStream в NATS 2.0+)
• Кластеризация для высокой доступности

Apache Pulsar

В последних проектах экспериментировал с Apache Pulsar, который сочетает преимущества Kafka и классических брокеров:

• Многоуровневое хранение (tiered storage)
• Built-in Geo-replication
• Отделение compute от storage

Паттерны и best practices

Паттерны работы с очередями:

1. Worker pool – пул горутин для обработки сообщений
2. Competing consumers – несколько обработчиков для одной очереди
3. Priority queues – обработка сообщений с разным приоритетом
4. Delayed messages – отложенное выполнение задач

Критические аспекты реализации:

• Идемпотентность обработчиков – защита от повторной обработки
• Мониторинг backlog – отслеживание глубины очередей
• Трейсинг сообщений – сквозная трассировка через correlation IDs
• Схемы сообщений – использование Protocol Buffers или Avro

Сравнительный анализ

Каждый брокер выбирался под конкретные требования:

Выводы

Мой опыт показывает, что не существует универсального брокера – выбор всегда зависит от конкретных требований проекта. В Go экосистеме для каждого брокера есть mature клиентские библиотеки, но важно учитывать нетипичные для Go проблемы – управление памятью при больших сообщениях, graceful shutdown обработчиков, и корректную обработку контекстов для прерывания операций.

Современный тренд – использование нескольких брокеров в одной системе, где каждый выполняет свою специализированную роль: Kafka для потоковой аналитики, RabbitMQ для синхронных задач, Redis для кэширования и быстрых pub/sub сценариев.