一句话答案

Seata AT 模式基于 SQL 解析自动生成 undo log，TC 协调 TM/RM 完成全局事务提交或回滚，对业务代码无侵入。

核心要点

→ 详见 Module 05 Q26（MySQL 分布式事务）

Seata 简介： 阿里开源的分布式事务解决方案，提供 AT、TCC、Saga、XA 四种事务模式。

AT 模式（Automatic Transaction，默认模式）：

原理：
  1. 拦截业务 SQL，生成 before image（执行前快照）
  2. 执行业务 SQL
  3. 生成 after image（执行后快照）
  4. 将 before/after image 写入 undo_log 表
  5. 提交本地事务（业务 SQL + undo_log 在同一个本地事务中）
  6. 全局提交 → 异步删除 undo_log
  7. 全局回滚 → 根据 before image 生成反向 SQL 回滚

特点：
  ✅ 对业务零侵入（只需加 @GlobalTransactional 注解）
  ✅ 自动生成回滚逻辑
  ❌ 性能一般（需要写 undo_log + 全局锁）
  ❌ 存在脏写风险（需要全局锁防止其他事务修改被锁定数据）

TCC 模式：

原理：业务层手动实现 Try / Confirm / Cancel 三个方法

特点：
  ✅ 性能最高（无 undo_log，无全局锁，资源锁定在 Try 阶段由业务控制）
  ✅ 灵活性强，可定制各种补偿逻辑
  ❌ 业务侵入性大，开发成本高
  ❌ 需要处理幂等、空回滚、悬挂问题

Saga 模式：

原理：
  将长事务拆分为多个短事务（本地事务）
  每个短事务对应一个补偿操作
  正向执行：T1 → T2 → T3 → ... → Tn
  异常回滚：Cn → ... → C3 → C2 → C1（依次执行补偿）

两种实现策略：
  编排式（Orchestration）：中央协调器控制流程（Seata 采用此方式）
  协同式（Choreography）：各服务通过事件驱动，无中央协调

特点：
  ✅ 适合长事务（如跨多个微服务的业务流程，耗时可能数分钟到数小时）
  ✅ 没有全局锁，并发度高
  ❌ 无隔离性（正向操作已提交，其他事务可能读到中间状态）
  ❌ 补偿操作设计复杂

三种模式对比与适用场景：

维度	AT 模式	TCC 模式	Saga 模式
业务侵入	无侵入	高（手写 Try/Confirm/Cancel）	中（需写补偿方法）
性能	中等	高	高
一致性	最终一致	最终一致	最终一致
隔离性	全局锁保证	业务自行保证	无隔离性
回滚方式	自动（undo_log）	手动（Cancel）	手动（补偿事务）
适用场景	常规 CRUD、中低并发	高并发金融场景（转账、支付）	长事务、跨多服务编排（订单流程）
典型应用	订单 + 库存 + 积分	转账、预扣款	旅行预订（酒店 + 机票 + 租车）

追问与易错

追问方向：

• AT 模式性能瓶颈在哪？
• Seata TCC 和通用 TCC 区别？
• TC Server 高可用怎么做？

易错点：

• ❌ AT 模式没有性能问题——全局锁有瓶颈
• ❌ AT 适合所有场景——跨数据源需用 TCC/SAGA

💡 记忆锚点

Seata 三模式选择口诀——AT：加个注解自动挡，undo_log帮你回滚，适合普通CRUD；TCC：手写三方法性能强，适合金融高并发；Saga：长链条补偿走，适合跨服务编排。核心角色：TC协调中心、TM发起方、RM资源方。