How RocketMQ Load Balancing Works and Best Practices to Avoid Consumer Delays

Load‑Balancing Timing

RocketMQ performs client‑side load balancing in coordination with the server. The MQClientInstance class handles communication and includes two key methods: rebalanceImmediately and doRebalance. Rebalancing is triggered at startup, every 20 seconds by default, and whenever the server notifies the client (e.g., client online/offline, heartbeat, or connection exceptions).

Load‑Balancing Strategies

The default strategy, AllocateMessageQueueAveragely , evenly distributes queues among consumers but may move many queues at once, which can cause larger consumption spikes when many clients are present.

Another option, AllocateMessageQueueConsistentHash , aims to move as few queues as possible during rebalancing, reducing disruption at the cost of occasional imbalance.

Example redistribution tables (converted from the original tables):

Average allocation with 4 clients and 24 queues: each client ends up with 8 queues after a peer goes offline.

Consistent‑hash allocation with the same setup: clients receive 8–9 queues, moving fewer queues overall.

Impact on Consumption

When a client leaves, newly assigned queues may be processed twice, requiring idempotent consumer logic. Conversely, queues that a client no longer owns experience a brief pause, which can create consumption spikes ("spikes") if the overall throughput is high.

A real‑world scenario shows consumption TPS dropping during application releases (around 21:00 and 21:50) because rebalancing delays the new consumers; after the release, the backlog is cleared quickly, causing a noticeable TPS surge.

Best Practices

Avoid frequent client up/down events; keep the number of online consumers stable.

Invoke the shutdown method before restarting or stopping a client so the server can trigger a graceful rebalance.

Choose the strategy that matches your workload: use the default average allocation for strict load balance, or consistent hashing to minimise consumption delay during restarts.

Ensure all clients use the same load‑balancing algorithm and identical subscription expressions; mismatches can lead to duplicate queue assignments or missed messages.

Message‑Level Load Balancing in RocketMQ 5.0

RocketMQ 5.0 introduces per‑message load balancing, allowing multiple consumers to read from the same queue while the broker locks each message until it is successfully processed or times out. This guarantees no duplicate consumption even with concurrent consumers.

The new mechanism also supports ordered consumption: messages belonging to the same group are locked and processed sequentially, preserving order across multiple consumers.