Mastering Distributed Transactions in Spring Cloud with Alibaba Seata AT Mode

Preface

We discuss how to solve the technical challenge of distributed transactions in Spring Cloud microservice architectures, covering three main topics: distributed transaction solutions, an introduction to Alibaba Seata middleware, and an analysis of Seata's AT mode implementation.

Distributed Transaction Solutions

In a monolithic application, a single database transaction can handle order creation, member points increase, and inventory reduction atomically. In a microservice environment, each service has its own database, leading to independent transactions that cannot be coordinated by a single database transaction, thus requiring a distributed transaction mechanism.

Two classic solutions are two‑phase commit (2PC) and three‑phase commit (3PC).

Two‑Phase Commit

The first phase is the transaction pre‑processing phase, where a new role, the Transaction Coordinator (TC), coordinates the start, commit, and rollback of branch transactions.

After local transactions complete, the coordinator moves to the second phase, the commit phase, sending commit commands to each service. If any service reports failure in the first phase, the coordinator triggers a rollback.

A fatal issue with 2PC is that if a service cannot receive the commit command due to network problems, the uncommitted data may remain locked, potentially causing system crashes.

To mitigate this, a timeout mechanism can be added to automatically commit locked data after a period, which may cause data inconsistency but prevents service collapse. This motivates the three‑phase commit.

Three‑Phase Commit

3PC splits the commit phase of 2PC into a pre‑commit phase and a commit phase, adding timeout mechanisms to avoid long‑lasting locks.

Phase 1: Transaction Pre‑processing

Identical to 2PC, it locks resources and processes local transactions.

Phase 2: Pre‑commit

All participants confirm readiness; both coordinator and participants set timeouts to prevent resource locking.

Phase 3: Commit

The final commit mirrors 2PC. If communication fails, the timeout on the service side forces a commit to release resources.

Compared with 2PC, 3PC reduces lock time but may compromise data consistency due to forced commits after timeouts. Companies address this with compensation tasks, end‑of‑day batch corrections, stricter integrity checks, and monitoring.

Alibaba Seata Distributed Transaction Middleware

Seata is an open‑source distributed transaction solution for microservices, offering AT, TCC, SAGA, and XA modes. AT mode provides a simple, non‑intrusive transaction mechanism by automatically generating reverse SQL for rollback.

Seata consists of three components: TC (Transaction Coordinator): maintains global and branch transaction states and drives commit or rollback. TM (Transaction Manager): defines the scope of a global transaction and decides when to commit or rollback. RM (Resource Manager): manages branch transaction resources, reports status, and executes commit/rollback.

Seata AT Mode Execution Process

The following pseudo‑code illustrates a member purchase scenario:

会员采购(){ 订单服务.创建订单(); 积分服务.增加积分(); 库存服务.减少库存(); }

The method acts as the TM, while the individual services act as RMs. Seata‑Server provides the TC.

During execution, each RM registers a branch transaction with the TC and writes undo logs (reverse SQL) to the UNDO_LOG table.

INSERT INTO order(id, ...) VALUES (1001, ...)

DELETE FROM order WHERE id = 1001

# Add points</code>
<code>UPDATE points SET point = 180 + 20 WHERE mid = 182</code>
<code># Undo log (subtract points)</code>
<code>UPDATE points SET point = 200 - 20 WHERE mid = 182

If all RMs succeed, the TM triggers a global commit, and the TC instructs each RM to commit and delete their undo logs. If any RM fails, the TM triggers a global rollback, and the TC instructs successful RMs to execute the undo SQL.

DELETE FROM order WHERE id = 1001

UPDATE points SET point = 200 - 20 WHERE mid = 182

Seata's AT mode achieves non‑intrusive global transaction management by leveraging Spring‑style declarative transactions on the TM side and automatic reverse‑SQL generation on the RM side.

Seata uses the "read uncommitted" isolation level, which can lead to dirty reads and phantom reads under high concurrency, so careful consideration is required.