Можешь рассказать о популярных системах обмена сообщениями и их особенностях?

Что хотят услышать интервьюеры:

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

Определение:

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

Популярные классы таких систем:

• Очереди сообщений — сообщение получает один потребитель; удобно для фоновой обработки и балансировки нагрузки.
• Pub/Sub — одно сообщение получают несколько подписчиков; подходит для событий и уведомлений.
• Стриминговые платформы — ориентированы на поток событий, хранение истории и повторное чтение; полезны для аналитики и интеграций.

Часто используемые решения:

• RabbitMQ — гибкий брокер очередей, хорошо подходит для классических очередей и маршрутизации.
• Apache Kafka — платформа для стриминга событий с высокой пропускной способностью и сохранением истории.
• Azure Service Bus / AWS SQS+SNS — облачные managed-решения для очередей и pub/sub.
• Redis Pub/Sub / Streams — лёгкие и быстрые варианты для простых сценариев, но с меньшим набором гарантий, чем у специализированных брокеров.

Пример использования:

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

// Условный пример: публикация события заказа в очередь/брокер
public record OrderCreated(Guid OrderId, decimal Total);

public async Task PublishOrderCreatedAsync(IMessageBus bus)
{
    var message = new OrderCreated(Guid.NewGuid(), 1250.50m);
    await bus.PublishAsync(message);
}

Пояснение кода:

В этом примере код несложный, но он показывает саму идею: приложение не вызывает напрямую другие сервисы, а публикует сообщение в шину.

Шаги:

1. Создаётся объект события OrderCreated с данными заказа.
2. Метод PublishAsync отправляет сообщение в брокер.
3. Подписанные сервисы получают это событие и обрабатывают его независимо.
4. Если один из потребителей временно недоступен, брокер может сохранить сообщение до обработки — это зависит от конкретной системы и настроек.

Ключевые моменты:

• Очереди хороши для распределения задач между несколькими воркерами.
• Pub/Sub подходит для событий, которые должны увидеть несколько подписчиков.
• Kafka сильна в потоках событий, высокой нагрузке и хранении истории.
• RabbitMQ часто выбирают за удобную маршрутизацию и классическую модель очередей.
• Облачные брокеры упрощают эксплуатацию, но привязывают к конкретному провайдеру.
• При выборе важны гарантии доставки, порядок сообщений, масштабирование и простота сопровождения.