How RocketMQ Guarantees Consistency with Transactions, Ordering, SQL Filters, and Delayed Messages

Consistency: Transaction Messages – Principle

RocketMQ’s first advanced feature is transactional messages, which ensure that a producer’s local transaction (e.g., database write) and the message‑sending transaction remain consistent. In a large e‑commerce scenario, a payment updates the order status in the database and then sends a message; without a transaction, failures can lead to dirty data such as paid orders not being shipped.

Transactional messages use a two‑phase commit combined with a compensation mechanism. The producer first sends a half (prepare) message, stores it in the broker, then executes the local transaction. After the local transaction succeeds, the producer sends a commit operation, which the broker writes to an OP queue, compacts, and makes the message visible to consumers. If the local transaction fails, a rollback is sent and the half message is discarded. If the producer crashes before sending commit/rollback, the broker periodically checks the producer’s transaction status and continues processing.

Consistency: Transaction Message Demo

A simple demo requires implementing a transaction status checker that queries the order database to determine whether an order is committed. The producer sends a prepare message, executes the local DB transaction, and then sends either commit (making the message consumable) or rollback (cancelling the half message). Consumer code remains unchanged from normal messages.

Consistency: Ordered Messages – Principle

Ordered messages guarantee that messages belonging to the same business key (e.g., an order ID) are stored in the same Topic partition and consumed sequentially by a single consumer, preserving business‑level ordering.

Consistency: Ordered Message Demo

When producing ordered messages, define a message group using a business ID (e.g., order ID). The same group maps to the same storage shard, ensuring serial processing. Consumers must use either push‑consumer or simple‑consumer mode, and their processing logic must remain single‑threaded per group to avoid breaking order semantics.

Complex Business: SQL Filtering – Principle

SQL filtering moves message selection from the consumer to the broker. Each message carries attributes (seller ID, buyer ID, price, status, etc.). Consumers can subscribe with an SQL expression, such as status='ordercreate' AND price BETWEEN 50 AND 100, and the broker returns only matching messages, reducing network and compute load.

Complex Business: SQL Filtering Demo

In the demo, messages are produced with custom properties like region='Hangzhou'. Three subscription cases are shown: (1) filter where region IS NOT NULL AND region='Hangzhou'; (2) filter combining region and price range; (3) a catch‑all subscription using TRUE to receive all messages.

Complex Business: Delayed Messages – Principle

Delayed messages become visible to consumers after a configured time interval, useful for scenarios like auto‑closing unpaid orders after 30 minutes. RocketMQ implements this with a TimerWheel where each tick (one second) holds a bucket of messages. A Timerlog links messages within the same tick, and when the wheel pointer reaches a tick, the bucket’s messages are flushed to the ConsumeQueue.

Global High Availability

Beyond intra‑cluster replication, RocketMQ supports global HA (multi‑active data centers). The architecture consists of four layers:

Access Layer: Distributes requests to multiple data centers based on a business ID.

Application Layer: Stateless services keep the entire request chain within a single data center to reduce latency.

Data Layer: Uses connectors to synchronize topic‑level data and consumer offsets across sites.

Global Control Layer: Manages routing rules, multi‑active metadata, and coordinated traffic switchover.

This design enables seamless failover during city‑level disasters, mitigates human‑error‑induced outages, and improves resource utilization by distributing load across regions.