basicQos 配合 prefetchCount 实现“能者多劳”而非轮询：它限制每个消费者最多持有 N 条未确认消息，处理快者及时释放空位持续接单，慢者被自动限流；须在 basicConsume 前手动设置且配合 manual ack。
RabbitMQ 的 basicQos 配合预取计数（Prefetch Count），不是用来实现“轮询”（Round-Robin）的，而是用来实现“能者多劳”（Fair Dispatch）的关键机制——它让空闲快的消费者多拿消息，忙的消费者少拿甚至不拿新消息，从而提升整体吞吐和资源利用率。
为什么 prefetchCount ≠ 轮询？
RabbitMQ 默认是轮询分发：不管消费者是否忙、处理多慢，只要 channel 开着，就平均发消息（每条都算在 unack 内）。这会导致慢消费者积压大量 unack 消息，拖垮整个队列吞吐。而 basicQos(prefetchCount = N) 的作用是：限制每个消费者最多持有 N 条未确认（unack）的消息。一旦达到 N 条，RabbitMQ 就暂停向该消费者投递新消息，直到它发来 ack（或 nack/reject）腾出空位。
这个机制天然支持“能者多劳”——处理快的消费者 ack 频繁，空位释放快，就能持续接新消息；处理慢的消费者长期占满 N 个位置，自然被“限流”，消息自动流向其他空闲消费者。
Java 客户端设置 prefetchCount 的正确方式
必须在 消费者开始消费前，且在 channel.basicConsume(...) 调用之前设置，否则无效。注意：该设置作用于当前 channel，不是全局或队列级。
立即学习“Java免费学习笔记（深入）”；
- 设置单个消费者最多处理 5 条未确认消息：
channel.basicQos(5); // 注意：参数是 prefetchCount，不是 global - 如果使用 Spring AMQP，应在
SimpleMessageListenerContainer中配置：container.setPrefetchCount(5); - 务必确保消费者手动 ack（
channel.basicAck()），否则消息永远不释放，消费者会被彻底“饿死”
关键细节与常见陷阱
忽略这些，prefetch 很可能失效：
- 不能设为 0：RabbitMQ 规定 prefetchCount ≥ 1；设 0 表示无限制（退化为默认轮询）
-
必须配合 manual ack：若使用 auto-ack（
autoAck=true），消息一送达即被 RabbitMQ 删除，prefetch 失去意义 -
作用域是 channel 级：一个 connection 下多个 channel，需各自调用
basicQos；不同消费者的 channel 互不影响 -
慎用 global 参数：
channel.basicQos(0, 5, true)中的true表示 global，即限制整个 connection 的所有 channel 总共不超过 5 条 unack —— 实际极少需要，容易误用
效果验证与调优建议
观察 RabbitMQ 管理界面的 “Ready”、“Unacked”、“Total” 列：
- 健康状态：各消费者 “Unacked” 数值动态波动，但基本稳定在 1~prefetchCount 区间
- 异常信号：某个消费者 “Unacked” 持续满格（如一直等于 5）、且 “Ready” 消息堆积 → 可能处理阻塞或未 ack
- 调优提示：从 1 开始试（最公平），逐步提高（如 5、10）；过高会削弱公平性，过低增加网络交互开销
