How RocketMQ Handles Distributed Transactions with Half Messages
Distributed transactions ensure atomicity across services, and RocketMQ provides a half-message mechanism with a two-phase commit and a rollback check that lets producers and consumers coordinate transaction steps reliably even when confirmations are delayed.
Distributed Transactions
First, recall what a transaction is. For example, a bank transfer where A sends 100 units to B consists of two steps: A's account decreases by 100, and B's account increases by 100.
A's account decreases by 100.
B's account increases by 100.
These two steps are placed in a single transaction to guarantee either complete success or complete failure.
In monolithic services this is easy to achieve with a single database transaction, but in distributed systems the steps may be handled by different sub‑services, introducing the concept of a distributed transaction.
RocketMQ offers transaction support that helps implement distributed transactions.
RocketMQ Solution Approach
Assume transaction T consists of logical steps T1 and T2 executed by systems A and B respectively.
A sends a pending (half) message M to RocketMQ (the message is not delivered to B yet; RocketMQ retains it) and then executes T1. After T1 finishes, A sends a second‑phase confirmation to RocketMQ.
If T1 succeeds, message M is marked as deliverable, allowing B to receive it; B then knows that A has completed T1 and only needs to complete T2. If T1 fails, RocketMQ discards M, so B never receives it.
This completes the distributed transaction.
The pending message is called a “half message”.
If A fails to send the second‑phase confirmation, RocketMQ’s check‑back mechanism will, after a timeout, query the producer for the local transaction result and act accordingly.
Detailed Step Description
Producer sends a transactional message to MQ.
MQ acknowledges receipt, forming the half message.
Producer executes its local transaction logic.
Producer sends a second‑phase confirmation (commit or rollback) to MQ. If commit, MQ makes the half message consumable; if rollback, MQ discards it.
If step 4 is missing, MQ performs a check‑back to the producer.
Producer checks the result of its local transaction.
Producer sends the final confirmation to MQ based on the check‑back feedback.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Java High-Performance Architecture
Sharing Java development articles and resources, including SSM architecture and the Spring ecosystem (Spring Boot, Spring Cloud, MyBatis, Dubbo, Docker), Zookeeper, Redis, architecture design, microservices, message queues, Git, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.