Qos限流像TCP滑动窗口

默认的轮询分发不考虑各消费者的实际处理速度，可能让处理快的消费者空闲、处理慢的消费者持续积压，拖累整体吞吐。RabbitMQ用channel.basicQos的prefetchCount参数限制每个消费者未确认消息的数量上限，达到上限后Broker停止向其推送新消息，直到消费者确认掉一部分，计数才释放——这个思路和TCP的滑动窗口本质相同：不是靠猜测处理能力做静态分配，而是靠”未完成的在途量”这个动态反馈信号自动匹配供需速度。发散：只要涉及”生产快于消费”的场景，用一个有限的在途配额做流控几乎是通用解法。