ApsaraMQ for RocketMQ uses different load balancing policies for producers and consumers. For consumers, the load balancing policy affects message accumulation.
Background information
In ApsaraMQ for RocketMQ, the load balancing policies are optimized based on the updates of the client SDKs. The following load balancing policies are available:
Load balancing policies compatible with the SDK for Java V2.x.x.Final and the SDK for C++ V3.x.x
Prerequisites
TCP client SDK for Java:
The TCP client SDK for Java is upgraded to V2.x.x.Final.
The instance must be deployed in one of the following regions: China (Hangzhou), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Hohhot), China (Shenzhen), China (Chengdu), Germany (Frankfurt), and Indonesia (Jakarta).
TCP client SDK for C++:
The TCP client SDK for C++ is upgraded to V3.x.x.
The instance can be deployed in any region.
Benefits
The load balancing policies that are compatible with the SDK for Java V2.x.x.Final and the SDK for C++ V3.x.x provide the following benefits:
Consumers can consume messages in a flexible manner. Consumers no longer consume messages based on queues. Messages in the same queue can be consumed by multiple consumers.
When the number of consumers exceeds the number of queues, no consumers remain idle. This helps avoid waste of resources.
Load balancing policy for producers
For unordered messages, producers send messages to queues in round-robin mode. Unordered messages are normal messages, transactional messages, scheduled messages, and delayed messages. The following figure shows an example.
In the preceding figure, three queues are available, and the numbers that follow "Msg" indicate the sequence of messages. The producer sends the first message to Queue 1, the second message to Queue 2, the third message to Queue 3, the fourth message to Queue 1, and subsequent messages in the same sequence.
For ordered messages, producers send messages that have the same shard key to the same queue. The following figure shows an example.
In the preceding figure, the producer sends all messages whose shard key is 1 to Queue 1 and all messages whose shard key is 2 to Queue 2.
Load balancing policy for consumers
For unordered messages, ApsaraMQ for RocketMQ brokers evenly distribute all messages in a topic to multiple consumers in a group.
If the SDK for Java V2.x.x.Final or the SDK for C++ V3.x.x is used to consume messages, load balancing is no longer performed based on queues. Messages in the same queue can be consumed by multiple consumers. The following figure shows an example.
In the preceding figure, multiple messages in each queue can be consumed by different consumers at the same time. For example, four messages in Queue 2 are distributed to Consumer 1, Consumer 2, Consumer 3, and Consumer 4 for consumption.
For ordered messages, ApsaraMQ forRocketMQ loads balance messages based on sharding keys. Messages that have different sharding keys can be load balanced to multiple queues for consumption. Messages that have the same sharding key are sent to the same consumer. This ensures that messages can be consumed in the order in which they are produced. The following figure shows an example.
Note
: Messages with this background color belong to Queue 1. Msg2-1 indicates that the message is the second message in Queue 1 and that the sharding key of the message is 1. 
: Messages with this background color belong to Queue 2. Msg3-2 indicates that the message is the third message in Queue 2 and that the sharding key of the message is 2.
In the preceding figure, Msg1-1, Msg2-1, and Msg3-1 are all consumed by Consumer 1 because these messages have the same sharding key 1. Likewise, the messages whose sharding key is 2 are all consumed by Consumer 2.
Msg4-3 and Msg4-4 are distributed to different consumers for consumption because their sharding keys are different.
Load balancing policies compatible with the SDK for Java V1.x.x.Final and the SDK for C++ V1.x.x and V2.x.x
Load balancing policy for producers
For producers, the load balancing policy that is compatible with the SDK for Java V1.x.x.Final and the SDK for C++ V1.x.x and V2.x.x is the same as that compatible with the SDK for Java V2.x.x.Final and the SDK for C++ V3.x.x. For more information, see Load balancing policies compatible with the SDK for Java V2.x.x.Final and the SDK for C++ V3.x.x.
For unordered messages, producers send messages to queues in round-robin mode.
For ordered messages, producers send messages that have the same shard key to the same queue.
Load balancing policy for consumers
The load balancing policy for unordered messages is the same as that for ordered messages.
The ApsaraMQ for RocketMQ architecture contains nodes such as brokers and name servers. A broker reports the route information about topics to a name server.
For example, your ApsaraMQ for RocketMQ architecture contains only one broker. After ApsaraMQ for RocketMQ sends messages from the producer to your topics, the messages in these topics are distributed among the eight queues by default. A queue is a logical concept. Then, the ApsaraMQ for RocketMQ broker evenly distributes these queues to consumers in the same group.
In ApsaraMQ for RocketMQ, a queue can be distributed to only one consumer at the same time. Each consumer processes messages from queues based on the following scenarios:
If the number of consumers is greater than the number of queues, the additional consumers do not process messages from the queues. The following figure shows an example.
If the number of consumers is equal to the number of queues, each consumer processes messages from one queue. The following figure shows an example.
If the number of consumers is smaller than the number of queues, each consumer may process messages in multiple queues. The following figure shows an example.
For consumers, load balancing is performed based on queues. A consumer may not process messages in a queue in a timely manner due to various reasons, such as hardware limits, system limits, issues related to remote procedure calls (RPCs), or Java garbage collection (GC). The messages in the queue may be accumulated.