Ensuring Ordered Message Processing in RocketMQ: Partitioning, Routing, and Consumer Coordination

To decouple systems, developers often introduce a Message Queue (MQ) framework where producers and consumers handle business processes independently.

Typical workflow:

Producer creates a message and sends it to the MQ server.

MQ stores the message in a partition of a topic.

Consumer pulls the message from the partition and processes it.

In practice, a single partition may not meet throughput requirements, so a multi‑partition architecture is adopted to distribute load and improve performance.

When an order‑related e‑commerce transaction generates multiple MQ messages (e.g., order , payment , shipment , confirmation ), the consumer must process them in the exact business state order; otherwise, inconsistencies arise.

The solution is to ensure that all messages belonging to the same logical order are placed in the same partition, achieving local ordering while allowing global parallelism.

RocketMQ provides a MessageQueueSelector interface to define custom routing logic:

public interface MessageQueueSelector {
    MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);
}

The selector receives the list of available queues ( mqs ), the message to send, and an optional argument ( arg ) that can be used for hashing or other strategies.

RocketMQ ships with three default implementations:

SelectMessageQueueByHash : uses the absolute hashcode of arg modulo mqs.size() to pick a queue.

SelectMessageQueueByRandom : selects a random index.

SelectMessageQueueByMachineRoom : returns null (placeholder for custom logic).

Although a single partition guarantees order, its consumer must be single‑threaded; multi‑threaded consumption would break ordering and may reduce performance.

To ensure that only one consumer processes a given queue, RocketMQ employs a locking mechanism:

During rebalance, it iterates over all MessageQueue objects of a topic and attempts to lock each one ( isOrder && !this.lock(mq) ).

Locked queues are assigned to a single consumer thread.

When scaling the number of partitions (e.g., expanding from 6 to 12), existing order‑related messages may be routed to new partitions, breaking order; therefore, it is recommended to finish processing existing messages before scaling or to use a temporary topic during migration.

If an ordered message fails, the consumer does not commit the offset, triggering automatic retries up to a limit; after exceeding the limit, the message is moved to a dead‑letter queue, allowing subsequent messages to continue processing.