一、前言
在使用 RabbitMQ 构建消息队列系统时，很多人都知道它有“轮询分发（Round-Robin Dispatching）”机制。
也就是说：
如果有多个消费者同时订阅同一个队列，RabbitMQ 会尽量让每个消费者轮流接收相同数量的消息。
听起来很“公平”，但实际运行中你可能会发现——
有的消费者几乎“忙不过来”，而另一些消费者却“闲得发慌”。
这，就是所谓的 不公平分发（Unfair Dispatching） 现象。
二、为什么会出现“不公平分发”？
RabbitMQ 默认是按轮询（round-robin）方式推送消息的，并不会实时了解每个消费者的“处理能力”或“忙碌程度”。
举个例子：
- 有两个消费者：Consumer A 和 Consumer B
- 队列中有 10 条消息
- A 每条消息要处理 1 秒
- B 每条消息要处理 100 毫秒
RabbitMQ 在默认配置下，会：
- 把第 1 条消息发给 A
- 把第 2 条消息发给 B
- 第 3 条再给 A
- 第 4 条再给 B
…
最终结果是：
B 很快处理完消息进入空闲状态，而 A 仍在忙碌；
但 RabbitMQ 仍会继续按顺序“公平”分配消息给 A。
久而久之，系统就出现了性能瓶颈——慢的拖慢整体速度。
三、核心原因：basicQos 的默认值
在 RabbitMQ 中，每个消费者可以通过设置 预取值（prefetch count） 来控制一次能拿多少消息。
默认情况下，这个值为 0（即不限数量）。
也就是说：
消费者一旦连接成功，RabbitMQ 会持续把消息推送给它，直到队列为空。
于是处理较慢的消费者，就会堆积一堆消息，而处理快的消费者反而得不到新的任务。
这就是“不公平分发”的本质。
四、解决方案：启用“公平分发（Fair Dispatch）”
想要让 RabbitMQ 尽可能“公平”分配消息，需要显式设置 basicQos 参数：
channel.basicQos(1);
这行代码的含义是：
告诉 RabbitMQ：同一时间内，最多只向该消费者推送 1 条未确认消息。
当消费者 ack 确认处理完成后，再分发下一条。
这样：
- 处理快的消费者，会更频繁收到消息；
- 处理慢的消费者，会自然被“限流”；
- 消息处理整体更高效。
一、前言
在使用 RabbitMQ 构建消息队列系统时，很多人都知道它有“轮询分发（Round-Robin Dispatching）”机制。
也就是说：
如果有多个消费者同时订阅同一个队列，RabbitMQ 会尽量让每个消费者轮流接收相同数量的消息。
听起来很“公平”，但实际运行中你可能会发现——
有的消费者几乎“忙不过来”，而另一些消费者却“闲得发慌”。
这，就是所谓的 不公平分发（Unfair Dispatching） 现象。
二、为什么会出现“不公平分发”？
RabbitMQ 默认是按轮询（round-robin）方式推送消息的，并不会实时了解每个消费者的“处理能力”或“忙碌程度”。
举个例子：
- 有两个消费者：Consumer A 和 Consumer B
- 队列中有 10 条消息
- A 每条消息要处理 1 秒
- B 每条消息要处理 100 毫秒
RabbitMQ 在默认配置下，会：
- 把第 1 条消息发给 A
- 把第 2 条消息发给 B
- 第 3 条再给 A
- 第 4 条再给 B
…
最终结果是：
B 很快处理完消息进入空闲状态，而 A 仍在忙碌；
但 RabbitMQ 仍会继续按顺序“公平”分配消息给 A。
久而久之，系统就出现了性能瓶颈——慢的拖慢整体速度。
三、核心原因：basicQos 的默认值
在 RabbitMQ 中，每个消费者可以通过设置 预取值（prefetch count） 来控制一次能拿多少消息。
默认情况下，这个值为 0（即不限数量）。
也就是说：
消费者一旦连接成功，RabbitMQ 会持续把消息推送给它，直到队列为空。
于是处理较慢的消费者，就会堆积一堆消息，而处理快的消费者反而得不到新的任务。
这就是“不公平分发”的本质。
四、解决方案：启用“公平分发（Fair Dispatch）”
想要让 RabbitMQ 尽可能“公平”分配消息，需要显式设置 basicQos 参数：
channel.basicQos(1);
这行代码的含义是：
告诉 RabbitMQ：同一时间内，最多只向该消费者推送 1 条未确认消息。
当消费者 ack 确认处理完成后，再分发下一条。
这样：
- 处理快的消费者，会更频繁收到消息；
- 处理慢的消费者，会自然被“限流”；
- 消息处理整体更高效。
五、示例对比
（1）不公平分发默认效果：
channel.basicQos(0); // 默认值，不限制
效果：
慢的消费者 backlog 堆积严重，快的消费者闲置。
（2）启用公平分发：
channel.basicQos(1); // 一次仅分发 1 条未确认消息
效果：
RabbitMQ 会动态调节分发速度，整体系统负载更均衡。
六、额外优化：ack 与持久化策略
别忘了配合 手动确认机制（manual ack） 使用，否则 RabbitMQ 无法判断消息是否处理完成。
示例：
boolean autoAck = false;
channel.basicConsume(queueName, autoAck, consumer);
consumer.handleDelivery(tag, env, props, body) -> {
// 处理业务逻辑
...
channel.basicAck(env.getDeliveryTag(), false); // 手动确认
};
这样可以避免消息丢失，同时结合 basicQos(1) 实现真正意义上的“按能力分发”。
七、总结
| 场景 |
默认行为 |
结果 |
解决方案 |
| 多消费者同时监听队列 |
轮询分发 |
快的闲、慢的累 |
设置 basicQos(1) |
| 消费者处理能力差异大 |
消息积压不均 |
系统吞吐下降 |
启用“公平分发” |
| 无手动 ack |
RabbitMQ 不知道处理状态 |
消息可能丢失 |
使用 basicAck |
✅ 建议：对性能要求较高的消费端，务必启用手动确认 + 限制预取值。
八、一句话总结
“公平分发”并非 RabbitMQ 的默认行为，
但只需一行代码，就能让你的队列系统更聪明、更高效。
