Зачем асинхронный обмен: очереди, pub/sub, события

↑ 5.4 Очереди и брокеры: Kafka, RabbitMQ · → Следующая

Обязательно~3 мин чтенияУровень: middle

Зачем это на собесе

Базовый вопрос про микросервисы: когда вызывать синхронно, а когда через брокер.

Объяснение

Синхронный вызов (HTTP/gRPC) связывает сервисы по времени: если получатель недоступен, отправитель ждёт или падает. Брокер сообщений разделяет их по времени, нагрузке и знанию друг о друге.

МодельКак работаетПример
Очередь (point-to-point)сообщение получает один потребительобработка задач, отправка писем
Pub/Subсообщение получают все подписчикисобытие OrderPaid для склада, биллинга, аналитики
Log (Kafka)упорядоченный журнал, потребители читают со своей позициипотоки событий, аналитика
Тип сообщенияСмыслПример
Команда«сделай X», адресована одному получателюSendEmail
Событие«произошло X», факт, подписчиков многоOrderPaid
Запрос/ответRPC поверх очередиредко

Преимущества: буферизация пиков, отказоустойчивость (получатель может быть выключен), независимое масштабирование, слабая связность. Цена: eventual consistency, сложная отладка, дублирование и порядок сообщений, дополнительная инфраструктура.

Нюансы и подводные камни

  • Событие называйте в прошедшем времени и описывайте факт; команду — в повелительном.
  • Не превращайте очередь в скрытый RPC: ожидание ответа возвращает связность.
  • Потребитель должен быть идемпотентным: доставка обычно at-least-once.
  • Следите за размером очереди и лагом потребителей.
  • Не всё нужно делать асинхронно: где нужен немедленный ответ — синхронный вызов.

Практика

  1. Разделите сценарий «оформление заказа» на синхронную часть и события.
  2. Нарисуйте потоки событий между сервисами.
  3. Определите, какие операции допускают eventual consistency.

Вопросы с ответами

Связанные темы