Mastering RocketMQ Transaction Messages: Theory, Flow, and Real‑World Example

1 Application Scenarios

In an e‑commerce checkout flow, a payment order is created, the order status changes from unpaid to paid after successful payment, and points are awarded to the user. Using a normal asynchronous consumption model can lead to inconsistencies such as lost points or mismatched order states, requiring compensation logic or transaction status queries.

2 Functional Principle

RocketMQ transaction messages guarantee eventual consistency between message production and local transactions in distributed environments. The workflow is:

Producer sends a message to the broker.

Broker persists the message and returns an ACK, marking the message as "pending delivery" (a half‑transaction message).

Producer executes the local transaction logic.

Producer sends a second‑phase commit or rollback result (Commit or Rollback) to the broker.

If the broker does not receive the second‑phase result due to network issues or producer restart, it performs a message status check after a fixed interval, prompting the producer to re‑evaluate the local transaction outcome and resend the appropriate confirmation.

3 Practical Example

A demo project simulates the payment order creation, payment success, and points awarding process.

Key steps:

Create a real order topic order-topic.

Create three tables in the database: order , transaction_log , and points .

Implement a producer that creates a payment order and updates its status, invoking sendMessageInTransaction which sends a half‑transaction message first, then runs the local transaction.

Configure a transactional producer and a transaction listener that implements local transaction execution and provides the broker with a status check interface.

The listener calls orderService.updateOrder, which is annotated with a transaction, updating the order status and inserting a transaction log atomically.

Based on the listener’s return ( LocalTransactionState.COMMIT_MESSAGE or LocalTransactionState.ROLLBACK_MESSAGE), the broker either delivers the message to consumers or discards it.

The consumer group subscribes to order-topic, processes messages idempotently, and inserts points records only when no existing record is found.

4 Summary

RocketMQ transaction messages enable distributed systems to maintain final consistency between message production and local database operations. Effective usage requires:

Cooperation between transactional producers and consumers.

Implementation of a transaction listener that records transaction outcomes (e.g., in a transaction log table).

Idempotent consumer logic with retry, alerting, and manual intervention mechanisms to ensure correct consumption results.