Seata AT 模式

某团队在选型分布式事务方案时，最终选择了 Seata AT 模式。

团队的理由：

AT 模式对业务代码无侵入——不需要实现 Try-Confirm-Cancel
Seata 自动管理 undolog，补偿过程透明
支持 AT、TCC、Saga 等多种模式

上线后发现问题：当并发量高时，Seata AT 模式的全局锁竞争严重，吞吐量反而不如 TCC 模式。

【架构权衡】 Seata AT 模式是最"无侵入"的分布式事务方案，但这也意味着它的锁粒度是"行锁"。在高并发场景下，全局锁会成为瓶颈。如果业务对并发能力要求高，需要评估是否应该选择 TCC 模式。

一、核心问题 🔴

1.1 AT 模式原理

Seata AT 模式原理：

┌─────────────────────────────────────────────────────────────────┐
│                      AT 模式执行流程                               │
│                                                                  │
│  阶段一：执行阶段                                                 │
│  ├─ 全局事务开启                                                 │
│  ├─ 执行 SQL（Seata 自动解析 SQL，生成 undolog）                │
│  ├─ 注册分支事务                                                 │
│  └─ 提交本地事务                                                 │
│                                                                  │
│  阶段二：完成阶段                                                 │
│  ├─ TC 通知所有分支提交/回滚                                     │
│  ├─ Seata 根据 undolog 自动回滚                                │
│  └─ 全局事务结束                                                 │
└─────────────────────────────────────────────────────────────────┘

1.2 undolog 自动补偿

undolog 的作用：

更新前：
  account: balance = 1000

SQL: UPDATE account SET balance = balance - 100 WHERE id = 1

Seata 自动生成 undolog：
  BEFORE: {"id": 1, "balance": 1000}
  AFTER: {"id": 1, "balance": 900}

提交时：删除 undolog
回滚时：根据 undolog 恢复数据

【架构权衡】 AT 模式的"无侵入"是有代价的：

需要解析 SQL，生成 undolog
全局锁由 TC 协调，锁粒度是行级
高并发下可能成为瓶颈

二、AT vs TCC

对比	Seata AT	Seata TCC
侵入性	无（自动处理）	高（需实现三阶段）
锁粒度	行级	业务可控
并发能力	低（全局锁竞争）	高（无全局锁）
适用场景	低并发、强一致性	高并发、最终一致

三、落地 Checklist

TC 部署：部署 Seata Server
undo_log 表：各数据库创建 undo_log 表
AT 模式配置：配置 Seata DataSource
性能评估：压测评估全局锁对吞吐的影响
模式切换：必要时切换到 TCC 模式

#Seata AT 模式

#一、核心问题 🔴

#1.1 AT 模式原理

#1.2 undolog 自动补偿