Продюсер не должен знать внутренности потребителя
Сервис-отправитель формирует сообщение по согласованному контракту и публикует его в exchange. Маршрутизация определяет, в какую очередь попадёт событие. Это позволяет подключать новых потребителей без изменения отправителя. Контракт сообщения должен быть версионируемым и достаточно стабильным, иначе слабая связность быстро превращается в скрытую зависимость.
Подтверждение защищает от потери работы
Потребитель подтверждает сообщение после успешной обработки. Если процесс упал раньше подтверждения, брокер может доставить сообщение повторно. Поэтому обработчик должен быть готов увидеть одно событие больше одного раза. Подтверждать сразу при получении проще, но тогда сбой после подтверждения способен привести к потере обработки.
Идемпотентность важнее надежды на единственную доставку
Даже при аккуратной конфигурации распределённая система должна учитывать повтор. Идентификатор события можно сохранять в базе и проверять перед созданием побочного эффекта. Другой подход — строить операцию так, чтобы повтор приводил к тому же состоянию, а не создавал вторую оплату, письмо или запись.
Ошибочные сообщения требуют отдельного пути
Если сообщение постоянно падает из-за неправильных данных, бесконечный retry только нагружает систему. Для таких случаев используют ограниченное число повторов и отдельную очередь ошибок. Метрики длины очередей, времени обработки и числа повторных попыток помогают увидеть проблему раньше, чем пользователи начнут жаловаться.
Попробуйте на практике
Спроектировать обмен между сервисом заказов и сервисом уведомлений.
- Опишите событие order_created с минимальным набором данных.
- Определите exchange, очередь и ключ маршрутизации.
- Решите, когда потребитель отправляет подтверждение.
- Добавьте идентификатор события для защиты от дублей.
- Опишите, что произойдёт после трёх неудачных попыток обработки.
Как проверить результат. Схема готова, если повторная доставка не создаёт повторного побочного эффекта, а неисправное сообщение не застревает в бесконечном цикле.
Частые вопросы
RabbitMQ заменяет HTTP API?
Нет. Синхронный API и сообщения решают разные задачи и часто используются вместе.
Можно ли гарантировать ровно одну доставку?
В прикладной системе безопаснее проектировать обработку с учётом возможных повторов, чем полагаться на абсолютную уникальность доставки.
Зачем нужна очередь ошибок?
Она отделяет проблемные сообщения от нормального потока и позволяет разбирать их без блокировки всей обработки.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.