Seata框架原理#

→ 相关：分布式事务方案

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）：各服务通过事件驱动，无中央协调

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

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

Seata是阿里开源的分布式事务框架，提供AT、TCC、Saga三种主要模式。核心角色有三个：TC（事务协调器）负责全局事务的协调，TM（事务管理器）负责发起全局事务，RM（资源管理器）管理分支事务的资源。最常用的是AT模式，对业务代码零侵入，只需要加一个@GlobalTransactional注解。AT的原理是拦截业务SQL，执行前生成before image快照，执行后生成after image，将两个快照写入undo_log表并和业务SQL在同一个本地事务中提交。全局提交时异步删除undo_log，全局回滚时根据before image生成反向SQL来恢复数据。AT的缺点是需要全局锁来防止脏写，性能一般。如果是高并发金融场景比如转账支付，建议用TCC模式，手动实现Try/Confirm/Cancel三个方法，性能最好但侵入性大。长链条跨服务编排用Saga模式。选择口诀就是：普通CRUD用AT自动挡，金融高并发用TCC手动挡，长事务编排用Saga。

追问方向：

• “AT 模式性能瓶颈在哪？”→ 全局锁（防脏写需要对修改行加全局锁）+ undo_log 写入（每次操作额外写 before/after image）+ TC 交互（注册和提交都要和 TC 通信）
• “Seata TCC 和通用 TCC 区别？”→ Seata TCC 提供了框架级支持（自动管理事务状态、超时回滚、幂等控制），开发者只需实现 Try/Confirm/Cancel 接口，比自己从零实现省很多
• “TC Server 高可用怎么做？”→ TC Server 部署集群 + 数据存储用共享数据库（MySQL）或 Redis，客户端通过 Nacos 注册发现 TC 集群节点，单点挂了自动切换

易错点：

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