Архитектура и надёжность

Каждый broker alias получает свой RabbitMQConnectionManager. В каждом потоке manager хранит раздельные producer и consumer connections; producer channel работает с confirms.

Разделение защищает от deadlock при публикации из handler, смешивания heartbeat/publish frames и общей зоны отказа при reconnect.

Гарантии доставки

Flask-RMQ даёт основу для at-least-once processing, но не exactly once:

• persistent message и durable queue переживают штатный restart брокера;
• confirm сообщает, что брокер принял публикацию;
• mandatory=True обнаруживает отсутствие маршрута;
• падение процесса после business commit, но до ack приводит к повторной доставке.

Делайте consumers идемпотентными: передавайте стабильный event ID и записывайте его с unique constraint в той же DB-транзакции, что и бизнес-изменение.

Transactional outbox

DB commit и RabbitMQ publish не являются общей транзакцией. Для важных событий:

1. сохраните business change и outbox row одной транзакцией;
2. dispatcher публикует незавершённые rows;
3. помечайте row доставленным только после confirm;
4. повторяйте с тем же event ID;
5. дедуплицируйте на consumer.

Та же схема нужна для нескольких брокеров: exchange делает fan-out только внутри одного RabbitMQ, а публикации в broker A и B неатомарны.

Handler errors направляйте через DLX в failure queue. После устранения причины используйте контролируемый replay, а не бесконечный автоматический requeue poison message.