How RocketMQ Solves Distributed Transaction Issues with Message Middleware

Preface

When systems become complex, distributed and micro‑service architectures require consideration of data partitioning, especially when data volume grows and databases need to be split.

For example, when registered user data becomes large, we need to consider database and table sharding.

Database splitting introduces many pain points, one of which is transaction consistency. The article examines how the problem arises in a simple transfer scenario where user A transfers 100 units to user B.

Scenario

After sharding, the architecture looks like the diagram below (image). When user A’s account is in cluster A and user B’s in cluster B, the two steps of deduction and addition are no longer in the same transaction, leading to possible data inconsistency.

In a monolithic database the two steps succeed or fail together, guaranteeing consistency. In a distributed setting they may succeed separately, causing incomplete data.

To solve this, the article introduces eventual consistency solutions using a message middleware.

Message Middleware Solution

(image) The idea is to make the deduction and addition asynchronous. After a successful deduction, a “deduction success” message is sent to the middleware; the addition service subscribes to this message and credits user B.

The message body must contain source account ID, target account ID, and amount.

Potential issues are discussed, such as the order of sending messages and performing deductions, which can lead to scenarios where one side succeeds while the other fails.

RocketMQ Transaction Scheme

RocketMQ splits a message into a Prepared phase and a Commit/Rollback phase. In the Prepared phase the message is stored only in the commit log and is invisible to consumers. In the Commit phase the message becomes visible in the consume queue.

During the Commit phase consumers can process the message; during Rollback the message is removed.

The article explains how RocketMQ performs periodic state checks (回查) on prepared messages. If the local business transaction succeeded, RocketMQ sends a commit message; otherwise it sends a rollback, ensuring eventual consistency.

This mechanism also resolves cases where the confirm message fails to send after a successful local transaction by re‑sending the commit after the check.

For the local transaction status check, the article suggests using a dedicated Transaction table that records the transaction ID and its completion status, allowing RocketMQ to simply verify this flag during the check.

Summary

The article presented a RocketMQ‑based distributed transaction solution, highlighted the importance of idempotent design on the consumer side, and posed an open question about applying the same pattern with other middleware such as RabbitMQ.