Причина, по которой RabbitMQ переключился с явного управления потоком на регулирование через обратное давление TCP, заключается в поддержке большего количества клиентов (многие из которых не могут обрабатывать асинхронные методы, такие как channel.flow
). К сожалению, способ, которым это сделано, и, возможно, способ, которым это должно быть сделано, полностью прозрачен для издателей - у нет способа , чтобы издатель мог сказать, когда его душат.
Если у вас действительно есть одна надежная гарантия публикации в реальном времени, ваш единственный выбор - ввести тайм-аут вручную. Конечно, это не решает основную проблему перегрузки RabbitMQ, поэтому остановка публикации, разрыв соединения и открытие нового не приблизит вас к повторной публикации.
Итак, вам нужно либо 1) пересмотреть, зачем вам нужны такие строгие гарантии для публикации, либо 2) добавить больше узлов в кластер RabbitMQ (который очень прост и предназначен именно для улучшения этой ситуации). ).