RabbitMQ 实战：理解“不公平分发（Unfair Dispatching）”机制

一、前言

在使用 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 参数：

1channel.basicQos(1);
2

这行代码的含义是：

告诉 RabbitMQ：同一时间内，最多只向该消费者推送 1 条未确认消息。
当消费者 ack 确认处理完成后，再分发下一条。

这样：

处理快的消费者，会更频繁收到消息；
处理慢的消费者，会自然被“限流”；
消息处理整体更高效。

五、示例对比

（1）不公平分发默认效果：

1channel.basicQos(0); // 默认值，不限制
2

效果：

慢的消费者 backlog 堆积严重，快的消费者闲置。

（2）启用公平分发：

1channel.basicQos(1); // 一次仅分发 1 条未确认消息
2

效果：

RabbitMQ 会动态调节分发速度，整体系统负载更均衡。

六、额外优化：`ack` 与持久化策略

别忘了配合 手动确认机制（manual ack） 使用，否则 RabbitMQ 无法判断消息是否处理完成。

示例：

1boolean autoAck = false;
2channel.basicConsume(queueName, autoAck, consumer);
3
4consumer.handleDelivery(tag, env, props, body) -> {
5    // 处理业务逻辑
6    ...
7    channel.basicAck(env.getDeliveryTag(), false); // 手动确认
8};
9

这样可以避免消息丢失，同时结合 basicQos(1) 实现真正意义上的“按能力分发”。

七、总结

场景	默认行为	结果	解决方案
多消费者同时监听队列	轮询分发	快的闲、慢的累	设置 basicQos(1)
消费者处理能力差异大	消息积压不均	系统吞吐下降	启用“公平分发”
无手动 ack	RabbitMQ 不知道处理状态	消息可能丢失	使用 basicAck

✅ 建议：对性能要求较高的消费端，务必启用手动确认 + 限制预取值。

八、一句话总结

“公平分发”并非 RabbitMQ 的默认行为，
但只需一行代码，就能让你的队列系统更聪明、更高效。

《RabbitMQ 实战：理解“不公平分发（Unfair Dispatching）”机制》是转载文章，点击查看原文。