Основная операция Publisher Confirms задокументирована на https://www.rabbitmq.com/confirms.html. Хотя в документации говорится о работе с входящими пределами (т. Е. Не допускать неограниченного), она, похоже, не обращается к исходящие лимиты.
Хотя RabbitMQ использует обратное давление TCP на основе памяти узла для ограничения публикации, это не исключает «чрезмерного количества неподтвержденных сообщений на канале подтверждения». (Многие сообщения могут уместиться в несколько ГБ ..)
Применяет ли RabbitMQ более агрессивные ограничения вменяемости к числу одновременных сообщений на канале подтверждения? Если нет, то код, который публикует агрессивно, создавая огромные наборы трекинга (на клиенте)?
Где документированы такие ограничения RabbitMQ в отношении невыполненных запросов подтверждения издателя (или они не существуют)? Изменилось ли поведение между версиями RabbitMQ (в любое время в 3.x)? Есть ли конкретная конфигурация для таких?
Локальные тесты получают только ~ 6k-7k ожидающих сообщений на канал - это ограничение примерно равно глобальной скорости публикации RabbitMQ в секунду. Число ожидающих сообщений на канал в основном не зависит от количества потоков / каналов ... не совсем уверен, как это можно интерпретировать и / или имеет ли отношение корреляция.
Панель инструментов RabbitMQ также отображает каналы как «поток», который гласит «Скорость публикации, недавно ограниченная сервером».