Understanding Ordered Messages in RocketMQ: Global and Partitioned Ordering

In business scenarios such as financial transactions, order fulfillment, and logistics tracking, maintaining message order is essential to avoid issues like overselling or accounting errors. RocketMQ addresses this need with a layered design that supports both global order and partition (local) order while delivering high performance.

Definition of ordered messages : RocketMQ guarantees that a message retains a specific sequence during sending, storage, and consumption. Two ordering models are provided:

Global Order (FIFO) – All messages within a single topic are processed strictly in FIFO order by configuring the topic with a single queue. This guarantees order but limits throughput to the capacity of one broker node, making it suitable only for small‑scale scenarios.

Partition Order – Messages are grouped (e.g., by order ID or user ID) so that messages belonging to the same group are placed in the same queue and processed sequentially, while different groups can be processed in parallel. This approach balances order guarantees with higher overall throughput.

Why ordered messages are needed? They ensure correct business flow (e.g., create → pay → ship), maintain data consistency, and prevent logical errors such as duplicate charges or stock inconsistencies.

Key implementation techniques

Producer side : Use a custom MessageQueueSelector to route messages with the same business key to the same queue, ensuring ordered sending. Example:

producer.send(msg, new MessageQueueSelector() {
    public MessageQueue select(List
mqs, Message msg, Object arg) {
        return mqs.get(Math.abs(orderId.hashCode()) % mqs.size()); // select queue by orderId hash
    }
}, orderId);

Key points include synchronous sending to preserve order, avoiding asynchronous sends that may cause reordering, and using fine‑grained sharding keys to prevent data skew.

Broker side : Messages are stored in MessageQueue according to the sharding rule, with the commit log guaranteeing sequential writes. Lock mechanisms (distributed rebalance lock, local queue lock, and global lock) prevent concurrent consumers from processing the same queue out of order.

Consumer side : Register a MessageListenerOrderly to consume messages from a single queue in a single thread, ensuring serial processing. Example:

consumer.registerMessageListener(new MessageListenerOrderly() {
    public ConsumeOrderlyStatus consumeMessage(List
msgs, ConsumeOrderlyContext context) {
        for (MessageExt msg : msgs) {
            // serial processing logic
        }
        return ConsumeOrderlyStatus.SUCCESS;
    }
});

RocketMQ’s default retry policy retries failed messages indefinitely (Integer.MAX_VALUE) to avoid backlog, while business logic must be idempotent to handle possible duplicate consumption.

Fault tolerance and resilience : The NameServer monitors broker health and triggers rebalancing when brokers are added or removed. Monitoring consumption progress, scaling consumer instances, avoiding long‑blocking operations, and employing asynchronous handling are recommended to prevent message pile‑up.

Design summary

Choose appropriate sharding keys to balance load and ordering.

Combine distributed and local locks on the broker to reduce concurrency conflicts.

Accept the trade‑off that ordered consumption may reduce throughput.

Implement retry strategies and idempotent processing to guarantee eventual consistency.

Through these mechanisms, RocketMQ achieves efficient and reliable message ordering in distributed environments, making it suitable for high‑concurrency scenarios that require strict sequencing.