Как обеспечиваются гарантии доставки сообщений в асинхронной модели (на примере RabbitMQ)?

Question

RabbitMQ обеспечивает разные гарантии доставки за счёт комбинации подтверждений от брокера (Publisher Confirms), подтверждений от потребителя (Consumer Acknowledgements), устойчивых сообщений (Persistent Messages) и механизма мёртвых писем (Dead Letter Exchange). Наиболее распространённая гарантия — "At Least Once" — достигается сохранением сообщения на диск и подтверждением его обработки потребителем.

YeaHub · Accepted Answer

В асинхронной коммуникации важно понимать, сколько раз и при каких условиях сообщение будет обработано.Гарантии доставки и обработки:At-Most-Once (Максимум один раз):Сообщение может быть потеряно, но никогда не будет доставлено дважды.Как достичь: Отключить подтверждения от брокера и потребителя. Сообщение удаляется из очереди сразу после отправки потребителю.Применение: Для некритичных данных, где скорость важнее надёжности (например, сбор метрик).At-Least-Once (Как минимум один раз):Сообщение гарантированно будет обработано, но возможно более одного раза (дублирование).Как достичь:Со стороны издателя: Включить Publisher Confirms и повторно отправить сообщение, если подтверждение не получено.Со стороны брокера: Сохранять сообщения на диск (persistent messages).Со стороны потребителя: Вручную отправлять подтверждение (ack) брокеру только после успешной обработки сообщения. Если потребитель упал, не отправив ack, брокер переотправит сообщение другому потребителю.Применение: Самый распространённый сценарий для бизнес-операций. Требует, чтобы обработка сообщения была идемпотентной.Exactly-Once (Ровно один раз):Сообщение будет обработано ровно один раз. Это очень сложно гарантировать в распределённых системах.Как достичь: На уровне RabbitMQ эта гарантия не поддерживается напрямую. Реализуется на уровне приложения с помощью идемпотентности потребителя и распределённых транзакций (например, с помощью паттерна "Outbox"), что создаёт большую нагрузку на производительность.Механизмы RabbitMQ для обеспечения надёжности:Persistent Messages: Сообщение помечается как persistent и сохраняется на диск. Это защищает от потери сообщений при перезагрузке брокера.Publisher Confirms: Издатель получает от брокера подтверждение, что сообщение было получено и (опционально) записано на диск.Consumer Acknowledgements (Ack/Nack): Потребитель явно сообщает брокеру, успешно ли он обработал сообщение (ack) или его нужно переотправить/отбросить (nack).Dead Letter Exchange (DLX): Очередь, из которой сообщения были отклонены (nack'нуты) или истек их TTL (Time-To-Live), перенаправляются в специальный обменник (DLX). Это позволяет анализировать и обрабатывать "проблемные" сообщения.Вывод:Практически достижимой и наиболее используемой является гарантия "At-Least-Once". Для работы с ней критически важно проектировать потребителей так, чтобы повторная обработка одного и того же сообщения не вызывала проблем (идемпотентность).