发布者确认的基本操作记录在https://www.rabbitmq.com/confirms.html中。虽然文档讨论了处理传入限制（即，不允许无限制）的问题，但它似乎并未解决传出的限制。
尽管RabbitMQ使用基于节点内存的TCP背压 来限制发布，但这并不排除“确认通道上未确认消息的数量过多”。 （许多邮件可以容纳几GB。）
RabbitMQ是否对确认频道上的并发消息数量应用更严格的合理性限制？如果不是，发布的代码是否会在客户端上积极创建巨大的跟踪集？
RabbitMQ对未完成的发布者确认请求有何记录（或不存在）？在RabbitMQ版本之间（在3.x中的任何时间），行为是否有所改变？对此有特定的配置吗？
本地测试仅在每个通道 上获得约6k-7k待处理消息-该限制与每秒每秒的RabbitMQ全局发布速度大致相同。每个通道的未完成消息 在很大程度上不受线程/通道数量的影响。.不确定如何解释和/或相关性是否相关。
RabbitMQ仪表板还将渠道显示为“流”，显示为“最近受服务器限制的发布率”。