Distributed Transaction Solutions: 2PC, TCC, Seata, Reliable Messaging, and Maximum‑Effort Notification

Distributed transactions arise when multiple services or databases must cooperate to complete a single logical operation, requiring careful handling of atomicity, consistency, isolation, and durability (ACID).

1. Basic Concepts

A transaction is an all‑or‑nothing set of operations; local transactions are typically managed by relational databases, while distributed transactions span multiple nodes.

Transactions can be seen as a large activity composed of smaller activities that either all succeed or all fail.

2. Distributed Transaction Scenarios

Microservice calls between order and inventory services.

Single‑process accessing multiple database instances.

Multiple services sharing the same database instance.

3. CAP Theory

CAP states that a distributed system can simultaneously satisfy at most two of Consistency, Availability, and Partition tolerance. The article discusses AP, CP, and CA combinations and their implications for system design.

4. BASE Theory

BASE (Basically Available, Soft state, Eventually consistent) extends CAP by relaxing strong consistency in favor of availability and partition tolerance.

5. Two‑Phase Commit (2PC)

2PC splits a transaction into a prepare phase and a commit phase. Traditional XA‑based 2PC requires database support and holds locks until the second phase, leading to performance penalties.

begin transaction;
// 1. Local DB operation: deduct amount from Zhang San
// 2. Remote call: add amount to Li Si
commit transaction;

6. Seata (AT and TCC Modes)

Seata is an open‑source framework that implements 2PC at the application layer, reducing lock time by committing the local transaction in the first phase.

1. Global transaction start with @GlobalTransactional
2. Each branch uses @Transactional
3. undo_log table records changes for rollback

7. TCC (Try‑Confirm‑Cancel)

TCC requires each branch to implement three operations: Try (resource reservation), Confirm (final commit), and Cancel (rollback). The article provides example code for a money transfer scenario, highlighting idempotency, empty rollback, and suspension handling.

// Try phase for Account A
if (!tryExecuted) { checkBalance(); deduct(30); }
// Confirm phase does nothing
// Cancel phase
if (tryExecuted) { addBack(30); }

8. Reliable Message (Eventual Consistency)

This approach stores a message in a local table within the same transaction as the business operation, then a background task reliably pushes the message to a broker (e.g., RocketMQ). Consumers acknowledge messages to ensure delivery.

begin transaction;
// Business logic
// Insert message log
commit transaction;

RocketMQ’s transactional messages provide built‑in support for atomicity between local DB changes and message sending.

9. Maximum‑Effort Notification

Here the sender pushes a notification to a broker; the receiver acknowledges receipt. If acknowledgment fails, the broker retries, and the receiver can also query the sender for the final status.

10. Comparative Analysis

A table summarizes the trade‑offs of 2PC, TCC, reliable messaging, and maximum‑effort notification in terms of consistency, throughput, and implementation complexity.

In conclusion, while no solution is perfect, choosing the appropriate pattern depends on the required consistency guarantees, performance constraints, and operational complexity of the distributed system.