雲訊息佇列 RocketMQ 版的訊息負載平衡策略針對生產者和消費者有所差異。對消費者而言，訊息負載平衡策略在一定程度上影響訊息堆積。
背景資訊
隨著SDK版本的升級，雲訊息佇列 RocketMQ 版的負載平衡策略也有所最佳化，根據SDK版本，負載平衡策略可分為：
負載平衡策略（用戶端Java v2.x.x.Final和C++ v3.x.x）
前提條件
TCP協議Java SDK：
SDK版本：升級至2.x.x.Final版本。
執行個體所屬地區：華東1（杭州）、華北1（青島）、華北2（北京）、華北3（張家口）、華北5（呼和浩特）、華南1（深圳）、西南1（成都）、德國（法蘭克福）和印尼（雅加達）。
TCP協議C++ SDK：
SDK版本：升級至3.x.x版本。
執行個體所屬地區：所有地區均支援。
優勢
用戶端Java v2.x.x.Final和C++ v3.x.x版本的負載平衡策略有以下優勢：
訊息消費更加靈活，不再按照Queue維度消費，同一Queue的訊息可以被多個消費者消費。
當消費者個數多於Queue的個數時，也不會產生消費者空轉的現象，避免資源浪費。
生產者負載平衡策略
無序訊息（普通訊息、事務訊息、定時和延時訊息）：Producer將訊息以輪詢的方式發送至Queue，如下圖所示：
圖中Msg1、Msg2代表第一條訊息、第二條訊息，生產者會把第一條訊息發送至Queue 1，然後第二條訊息發送至Queue 2，第三條訊息發送至Queue 3，以此類推，第四條訊息又發送至Queue 1，迴圈往複。
順序訊息：相同Sharding Key的訊息被發送至同一個Queue，如下圖所示：
圖中ShardingKey為1的訊息都同時被發送到Queue1中，同樣Sharding Key為2的訊息同時被發送至Queue 2中。
消費者負載平衡策略
無序訊息：雲訊息佇列 RocketMQ 版Broker按照訊息維度將Topic中的所有訊息平均分配給消費者叢集中的多個消費者處理。
用戶端Java v2.x.x.Final和C++ v3.x.x版本的負載平衡不再按照Queue維度消費，同一Queue的訊息可以被多個消費者消費。具體樣本如下圖所示：
圖中每一個Queue中的多條訊息都可同時被不同的消費者消費，例如Queue 2中的四條訊息被分配給了Consumer 1、Consumer 2、Consumer 3及Consumer 4消費。
順序訊息：訊息消費根據Sharding Key負載平衡，不同Sharding Key的訊息可被均衡的負載到多個Queue中消費，且為保證順序訊息的語義，相同Sharding Key的訊息會被同一個消費者消費，具體樣本如下圖所示：
說明
：該表徵圖背景色表示訊息屬於Queue 1；Msg2-1表示該訊息為Queue1中的第2條訊息，且訊息的ShardingKey為1。
：該表徵圖背景色表示訊息屬於Queue 2；Msg3-2表示該訊息為Queue2中的第3條訊息，且訊息的ShardingKey為2。
圖中Msg1-1、Msg2-1和Msg3-1這三條訊息的Sharding Key都是1，因此被同一個消費者Consumer 1消費，同樣Sharding Key都為2的訊息同時被Consumer 2消費。
Msg4-3和Msg4-4的Sharding Key不同，分別為3和4，因此可被分配給不同的消費者消費。
負載平衡策略（用戶端Java v1.x.x.Final和C++ v1.x.x/v2.x.x）
生產者負載平衡策略
與用戶端Java v2.x.x.Final和C++ v3.x.x的負載平衡策略相同，具體樣本，請參見負載平衡策略（用戶端Java v2.x.x.Final和C++ v3.x.x）。
無序訊息：Producer的訊息以輪詢的方式發送至Queue。
順序訊息：相同Sharding Key的訊息被發送至同一個Queue。
消費者負載平衡策略
無序訊息和順序訊息的負載平衡策略相同。
雲訊息佇列 RocketMQ 版包含Broker和Name Server等節點，其中Broker節點負責將Topic的路由資訊上報至Name Server節點。
假設目前雲訊息佇列 RocketMQ 版只有一個Broker節點，訊息從Producer發送至雲訊息佇列 RocketMQ 版的Topic，預設會將這些Topic下的訊息均衡負載至8個Queue（邏輯概念）。雲訊息佇列 RocketMQ 版Broker會將這些Queue再平均分配至屬於同一個Group ID的消費者叢集。
在雲訊息佇列 RocketMQ 版中，一個Queue只能同時被分配至一個消費者消費。因此，每台消費者機器處理的Queue的數量有以下幾種可能：
若消費者機器數量大於Queue的數量，則超出Queue數量的機器會處理0個Queue上的訊息，如下圖所示：
若消費者機器數量等於Queue的數量，則每台機器會處理1個Queue上的訊息，如下圖所示：
若消費者機器數量小於Queue的數量，則每台機器會處理多個Queue上的訊息，如下圖所示：
因為消費者負載平衡策略是以Queue為粒度維護，如果消費者叢集中一台機器處理變慢，可能是機器硬體、系統、遠程RPC調用或Java GC等原因導致分配至此機器上的Queue的訊息不能及時處理，則整個Queue上的訊息都會堆積。