Master Distributed Transaction Consistency: 2PC vs MQ Solutions for Java Interviews

Case Background

In distributed internet scenarios, a monolithic system is split into multiple subsystems. A single write operation must coordinate several systems, leading to the distributed transaction problem: a large operation composed of many small operations across different servers must either all succeed or all fail.

We use the JD Travel system as an example. The original .NET transaction system was rewritten in Java and split into Product, Promotion, and Order subsystems. When a user places an order, the Order service creates the order, the Product service deducts inventory, and the Promotion service deducts coupons. Only when all three subsystems commit does the order succeed.

Case Analysis

This is a typical distributed‑transaction scenario. Common solutions include Two‑Phase Commit (2PC), 3PC, TCC, and message‑queue‑based implementations.

Many candidates immediately propose 2PC, describing its process, but in practice most internet companies prefer reliable message delivery via MQ because the classic protocols are rarely used.

Solution 1: Two‑Phase Commit (2PC)

Protocol Overview

2PC is the classic protocol for distributed transactions. It consists of a prepare phase and a commit phase, each involving a Coordinator and Participants.

Coordinator = Transaction Manager

Participant = Resource Manager (e.g., a database)

In Java, XA defines the interface between a Transaction Manager and Resource Managers. JTA (Java Transaction API) implements XA. Spring can configure a JtaTransactionManager to manage multiple ResourceManagers and thus multiple databases. How does 2PC actually run? In our order‑product‑promotion example, the business logic runs on an application‑server cluster, which accesses three separate databases (D1, D2, D3) via Spring. The JTA transaction manager acts as the coordinator, while each database acts as a resource manager.

Assume order data is stored in D1, product data in D2, and promotion data in D3. Prepare Phase: The transaction manager asks all resource managers to start a transaction and prepare to commit. Each manager writes undo/redo logs and replies "Yes" if ready.

Commit Phase

: After receiving "Yes" from all participants, the coordinator sends a commit command. Each database commits locally and acknowledges.

Abort Phase

: If any participant replies "No" (e.g., a lock cannot be obtained), the coordinator issues a rollback. Participants use the undo log to revert changes.

Key drawbacks of 2PC

Locking: Each resource manager must lock rows (e.g., MySQL row lock). If another request modifies the data before commit, overselling can occur.

Deadlocks: Locks can cause deadlock, especially if a failure occurs during the commit phase.

Performance: Locked rows block other transactions, leading to high latency.

Inconsistency: Network failures after the commit command can leave some databases committed and others not, breaking consistency.

Solution 2: Reliable Message Delivery via MQ

Message‑queue‑based reliable delivery is the most common approach in high‑concurrency internet systems. It sacrifices strong consistency for eventual consistency, improving availability.

In the order scenario, the Order service puts a "deduct coupon" event into a queue. The Coupon service consumes the event later. Because the message is persisted, even if the MQ crashes and restarts, the event is not lost.

Key interview points for MQ solutions: Message loss caused by automatic acknowledgments: If the consumer fails after auto‑ack, the message is removed and lost. Manual ack after successful business processing prevents this. Message backlog in high‑traffic spikes: Excessive load can cause messages to pile up and eventually be dead‑lettered.

To achieve double‑confirmation, the producer should persist the message locally with a "pending" status, send it to the MQ, and the consumer, after successful processing, sends a confirmation message back. The producer then marks the local record as "completed". If the MQ loses the message, a scheduled task can scan pending records and resend them.

Summary

Understanding distributed transaction consistency is essential for both junior and senior engineers. MQ‑based reliable delivery is the practical solution in most internet scenarios because it provides decoupling and traffic‑shaping benefits, while 2PC is mainly a theoretical concept useful for demonstrating knowledge.

When answering interview questions, focus on the double‑confirmation principle for MQ solutions and be aware of 2PC’s locking, deadlock, performance, and consistency issues.