Mastering Distributed Transactions: From 2PC to Seata AT Mode

0. Introduction

From CPU to memory, disk, OS, and network, computer systems contain many unreliable factors. Engineers use various software and hardware techniques—TCP for reliable transmission, RAID for storage, ARIES‑based transaction mechanisms for databases—to ensure correct processing of data and instructions.

This article first introduces the ACID properties of single‑node database transactions, then highlights the difficulties of operating multiple data sources in distributed environments, and finally presents common distributed‑transaction solutions that allow business code to achieve ACID characteristics across multiple data sources. The discussion concludes with an in‑depth look at the Seata framework’s AT mode implementation.

1. Single‑Data‑Source vs Multi‑Data‑Source Transactions

A single‑data‑source transaction (local transaction) can rely on the database’s built‑in transaction mechanism to guarantee atomicity, consistency, isolation, and durability (ACID). In a micro‑service architecture, each service maintains its own database, so a business operation often spans multiple services and databases, requiring a distributed transaction to preserve ACID semantics.

2. Common Distributed Transaction Solutions

2.1 Distributed Transaction Model

Key roles include Transaction Participants (e.g., each database), Transaction Coordinator (the service that accesses multiple data sources), Resource Manager (often synonymous with participant), and Transaction Manager (often synonymous with coordinator). The TM manages multiple RMs, coordinating local transactions to achieve global ACID properties.

2.2 Two‑General Problem and Idempotency

The classic two‑general problem illustrates uncertainty in network communication: a messenger may be captured, leaving the receiver unaware of the command. This mirrors real‑world scenarios where a client cannot determine whether a request succeeded, leading to the need for idempotent operations.

2.3 Two‑Phase Commit (2PC) & Three‑Phase Commit (3PC)

2PC consists of a prepare phase (participants report readiness) and a commit phase (coordinator instructs participants to commit or roll back). While conceptually simple, 2PC suffers from performance bottlenecks, lock contention, and coordinator failure risks. 3PC adds a timeout‑based inquiry phase to mitigate blocking but still cannot fully address crash scenarios.

2.4 TCC (Try‑Confirm‑Cancel)

TCC implements a service‑level two‑phase commit: a try phase locks resources, a confirm phase commits if all tries succeed, and a cancel phase rolls back otherwise. Idempotent confirm/cancel operations are required, often achieved via deduplication tables.

2.5 Transaction‑Status‑Table Scheme

The coordinator maintains a status table tracking the progress of each sub‑operation. A background task scans the table and retries incomplete steps until the transaction reaches a final success or error state, with each service ensuring idempotent handling based on the global transaction ID.

2.6 Message‑Queue Based Final Consistency

This approach uses a message broker (e.g., RabbitMQ) to achieve eventual consistency. The order service writes an order record and a local message within a single transaction; the repo service consumes the message, updates inventory, and acknowledges the broker. Retries and deduplication guarantee no loss or duplicate processing, while the overall system attains high concurrency and final data consistency.

3. Seata in AT Mode Implementation

Seata provides AT, TCC, SAGA, and XA modes. AT mode intercepts SQL statements, records custom undo logs, and uses a two‑phase commit that releases local locks after the first phase, improving concurrency.

3.1 AT Mode Workflow Overview

The global transaction is registered with Seata, branches register their local transactions, local commits occur, and Seata aggregates branch statuses to decide global commit or rollback. In the commit case, branches simply delete their undo logs; in the rollback case, they replay undo logs to compensate.

3.2 AT Mode Detailed Workflow

Example: a user purchases a mouse, requiring inventory decrement and order insertion. The first phase records undo logs for both services; the second phase either deletes those logs (commit) or replays them (rollback). Global locks ensure isolation during concurrent transactions.

Undo logs contain before‑image and after‑image data, enabling precise compensation. Seata also supports global read/write isolation via global locks and SELECT FOR UPDATE proxies.

4. Conclusion

All discussed solutions—2PC, 3PC, TCC, transaction‑status tables, Seata AT mode, and message‑queue based eventual consistency—share the core idea of a coordinator managing local transactions to achieve global ACID properties, though they differ in performance, complexity, and adherence to standards like XA.