Master Distributed Transactions with Seata: From Theory to AT Mode Implementation

What is a Distributed Transaction?

Distributed transactions occur when multiple services cooperate over a network to complete a single logical transaction, such as order creation with inventory deduction or bank transfers.

CAP Theorem

The CAP theorem states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition tolerance. Typically, systems sacrifice strong consistency to achieve availability and partition tolerance.

Consistency Types

Strong consistency

Weak consistency

Eventual consistency

Transaction Solutions

Various patterns address distributed transactions:

Two‑Phase Commit (2PC)

Coordinates a prepare phase and a commit phase; drawbacks include performance bottlenecks and single‑point failure.

Three‑Phase Commit (3PC)

Improves 2PC by adding timeout handling and an extra pre‑commit phase, reducing blocking.

TCC (Try‑Confirm‑Cancel)

Application‑level two‑phase commit where each operation registers confirm and cancel actions.

Local Message Table

Splits a global transaction into local ones and uses a message table to guarantee eventual consistency.

MQ Transaction (Reliable Message)

Encapsulates the local message table inside a message queue (e.g., RocketMQ) to reduce coupling.

Maximum Effort Notification

Enhances MQ transactions by allowing the consumer to pull missing messages.

Saga

Chains a series of local transactions with compensating actions; can be orchestrated (command) or choreographed (event).

Seata Overview

Seata is an open‑source distributed‑transaction framework offering AT, TCC, Saga, and XA modes with minimal intrusion.

AT Mode

AT mode uses a two‑phase commit where the first phase records business SQL and undo logs, and the second phase either commits or rolls back using the undo log.

Setting Up Seata TC (Coordinator)

Download Seata (e.g., 1.3.0) and unzip.

Create the required tables (global_table, branch_table, lock_table) in MySQL.

Configure registry.conf to use Nacos as the registry.

Push the TC configuration (config.txt) to Nacos using nacos-config.sh.

Set the database connection properties (store.db.*) in Nacos.

Start seata-server.bat and verify registration in Nacos.

Building Seata Clients (RM)

Each microservice (storage, account, order) adds Seata dependencies matching the server version, creates its own database with an undo_log table, and configures Nacos for registry and configuration.

Storage Service

Provides an endpoint to deduct inventory; annotated with @Transactional for local transaction.

Account Service

Provides an endpoint to deduct user balance; also uses @Transactional.

Order Service (TM)

Uses @GlobalTransactional to start a global transaction, calls storage and account services via OpenFeign, and creates an order record.

Testing

Running all services and invoking the order API shows successful commit; introducing a timeout in the account call triggers a rollback, confirming Seata’s AT mode works.

Key Takeaways

Seata client version must match the server.

Every service database needs an undo_log table.

Transaction group names must be configured in Nacos (e.g., service.vgroupMapping.seata-storage-tx-group=default).