Seata 中 TC 二阶提交机制核心

一、先明确：Seata 二阶提交的角色定位

在 Seata 分布式事务中，TC（Transaction Coordinator，事务协调者） 是核心调度角色，负责协调全局事务的"提交/回滚"，而"二阶提交"是 Seata 实现分布式事务一致性的核心流程（Seata AT 模式的核心逻辑）。

二、我的理解：Seata TC 二阶提交的核心逻辑

你的理解已覆盖核心，但需要补充 "全局锁""前/后镜像"的作用细节，完整逻辑是：

1. 一阶（准备阶段）：

• • 各分支事务（如订单、库存服务）执行本地业务 SQL，同时 Seata 会自动生成"前镜像"（SQL执行前的数据）、"后镜像"（SQL执行后的数据） ，并将这两个镜像 + 分支事务ID 写入本地数据库的 undo_log 表；
  • 本地事务提交（此时业务数据已写入数据库，但 undo_log 保留）；
  • 分支事务向 TC 上报"准备完成"状态，同时 TC 会给该分支事务操作的数据加**"全局锁"**（防止其他分布式事务修改同一数据，避免脏写）。

1. 二阶（提交/回滚阶段）：

• • 提交场景 ：TC 收到所有分支事务的"准备完成"后，向所有分支发送"提交指令"；各分支删除本地 undo_log，释放全局锁，全局事务完成。
  • 回滚场景 ：TC 收到任意分支的"失败"后，向所有分支发送"回滚指令"；各分支根据 undo_log 中的前镜像恢复数据（覆盖后镜像），恢复完成后删除 undo_log，释放全局锁，全局事务回滚。

三、Seata TC 二阶提交完整笔记

1. 核心概念铺垫

• TC（事务协调者）：Seata 的核心组件，负责全局事务的创建、状态协调、指令下发。
• undo_log：Seata 自动生成的"回滚日志表"，存储前镜像、后镜像、分支事务ID，是回滚的核心依据。
• 全局锁：TC 维护的"数据级锁"，保证同一数据在分布式事务中不会被并发修改，避免数据不一致。

2. 一阶：准备阶段（本地事务提交 + 日志/锁准备）

流程

1. 业务系统发起分布式事务，TC 生成全局事务ID；
2. 各分支事务（如订单服务、库存服务）执行本地业务 SQL（如扣减库存、创建订单）；
3. Seata 拦截 SQL，自动生成：

• • 前镜像：SQL执行前的数据快照（用于回滚时恢复）；
  • 后镜像：SQL执行后的数据快照（用于校验数据是否被其他事务修改）；

1. 分支事务将「前镜像 + 后镜像 + 分支事务ID」写入本地 undo_log 表；
2. 分支事务提交本地事务（此时业务数据已落地，undo_log 保留）；
3. 分支事务向 TC 上报"准备完成"，TC 给该分支操作的数据加全局锁。

3. 二阶：提交/回滚阶段（TC 统一调度）

场景1：全局提交

• 触发条件：TC 收到所有分支事务的"准备完成"状态；
• 流程：

1. 1. TC 向所有分支事务发送"提交指令"；
   2. 各分支事务删除本地 undo_log 表中的对应记录；
   3. 各分支释放全局锁；
   4. TC 标记全局事务为"已提交"。

场景2：全局回滚

• 触发条件：TC 收到任意分支事务的"失败"状态（或超时未响应）；
• 流程：

1. 1. TC 向所有分支事务发送"回滚指令"；
   2. 各分支事务读取本地 undo_log 中的前镜像，用前镜像覆盖当前数据（完成回滚）；
   3. 回滚完成后，各分支删除本地 undo_log 表中的对应记录；
   4. 各分支释放全局锁；
   5. TC 标记全局事务为"已回滚"。

4. 关键细节补充

• 前/后镜像的作用：

• • 前镜像：回滚时恢复数据的"原始版本"；
  • 后镜像：回滚前校验数据是否被其他事务修改（若后镜像与当前数据不一致，说明数据被脏写，Seata 会抛出异常）。

• 全局锁的意义 ：
  分布式场景下，若没有全局锁，分支事务提交后、全局提交前，其他事务可能修改同一数据，导致回滚失败；全局锁保证了数据在分布式事务期间的"独占性"。
• undo_log 的生命周期 ：
  仅在"一阶完成、二阶未完成"期间存在，二阶提交/回滚后会被删除，不会长期占用存储。

5. 总结

Seata TC 的二阶提交是"先准备、后统一决策"的模式：

• 一阶做"业务执行 + 回滚准备 + 锁准备"，保证"能提交也能回滚"；
• 二阶由 TC 统一调度"提交/回滚"，通过 undo_log 实现回滚、通过全局锁保证数据一致性；
• 核心目标是在分布式场景下，实现"要么所有分支事务都成功提交，要么所有分支都回滚"的最终一致性。