一、前言

       在使用 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) 實現真正意義上的“按能力分發”。

七、總結

✅ 建議：對性能要求較高的消費端，務必啓用手動確認 + 限制預取值。

八、一句話總結

“公平分發”並非 RabbitMQ 的默認行為，
但只需一行代碼，就能讓你的隊列系統更聰明、更高效。