Seata分布式事务框架

可视化演示

展示Seata分布式事务TC/TM/RM协作架构、全局事务流程与AT/TCC/SAGA/XA四种模式对比。

三大角色

想象演唱会的后台：执行导演 TM 站在舞台侧幕，手里攥着节目单，决定“整场演唱会什么时候开始、什么时候结束”。总控台 TC 坐在音控室里，面前的屏幕上实时显示后台每一个小组的状态，哪盏灯没亮、哪支麦克风没通，他全知道。而灯光组、音响组、道具组的组长 RM 们，则带着各自的团队完成自己负责的那部分工作，完成后向总控台大声汇报一句“我们组 OK 了”。

Seata 把这套分工做成了软件架构的三个角色。TM（Transaction Manager）事务管理器负责全局事务的发起、提交和回滚决策，相当于执行导演；TC（Transaction Coordinator）事务协调者负责维护全局事务的运行状态，协调每个分支的注册与最终结果，相当于总控台；RM（Resource Manager）资源管理者则管理每个分支事务里的本地资源，比如数据库行记录、表锁等，相当于各组组长。

在协作机制上，三者的关系可以总结成一句话：TM 只管下命令，TC 负责传话和汇总，RM 负责干活。TM 向 TC 发起一个全局事务时，TC 会生成一个全局事务 ID（XID）；RM 执行本地操作时会用这个 XID 向 TC 注册分支事务；最后 TM 根据业务是否全部成功，向 TC 下达提交或回滚的指令。

一场演唱会的成败，取决于各组组长能否及时如实向总控台汇报，总控台能否准确判断整体状态。Seata 的三大角色也是如此：职责清晰、各司其职，才能在跨服务的复杂环境下不乱套。

AT模式

现在演出正式开始了。灯光组组长在按下灯光按钮之前，先让助理对着控制台拍了一张“当前灯光亮度”的照片存档。如果之后演出出了意外需要恢复，他们照着照片把亮度调回去就行——这就是 AT 模式最核心的思路：给业务数据拍快照，出错就还原。

AT 模式分为两个阶段。一阶段：RM 在自己的本地数据库里执行业务 SQL，同时把修改前后的数据镜像（before image 和 after image）写入一张名为 undo_log 的日志表。执行完后，本地事务直接提交，释放本地数据库的行锁。二阶段：TC 汇总所有 RM 的上报结果，如果全部都成功，则通知各 RM 删除 undo_log 中的快照，完成提交；如果任何一个分支失败，TC 通知所有 RM 依据 undo_log 中的 before image 逆向生成回滚 SQL，把数据恢复原状。

这里的关键是全局锁。在分布式场景下，两个全局事务可能操纵同一行数据。本地事务提交后行锁已释放，为了让另一个事务的修改不会破坏当前事务的一致性，TC 会为涉及的行分配一把逻辑上的“全局锁”。任何分支在修改数据前，必须先向 TC 申请到这把锁，而全局锁要等到二阶段结束（提交或回滚完成）才释放。

演出结束后，助理把存档照片全部删掉，控制台上的一切恢复如常。AT 模式对业务代码几乎零侵入——你不用写任何补偿逻辑，数据库行锁也只短暂占用，适合大多数对一致性要求较高的业务场景。

TCC模式

如果舞台道具非常昂贵，灯光组不会直接下单买下，而是先给供应商打电话“预留一套设备”，供应商记下预约单，但不发货。等演出方案最终敲定，再打第二个电话“确认发货”；如果演出取消，就打第三个电话“取消预约”，供应商撤销预约单。这就是 TCC 模式的业务逻辑：Try 预占资源，Confirm 确认提交，Cancel 取消还回去。

TCC 的三个阶段分别对应三个业务方法。Try 阶段：尝试预占资源，比如冻结账户里的余额、锁定库存数量，此时数据并未真正变化。Confirm 阶段：如果 Try 阶段所有分支都成功，TC 通知各 RM 执行 Confirm，把预占真正变成扣款、扣减库存。Cancel 阶段：如果 Try 阶段有分支失败，TC 通知各 RM 执行 Cancel，把 Try 预占的资源释放回原处。

TCC 的代价是业务侵入性很强。每个参与事务的服务都要自己写 Try、Confirm、Cancel 三个方法，而且要处理幂等、空回滚和悬挂等边界问题。比如网络超时导致 Confirm 重复下发，业务代码必须能识别重复请求；再比如 Try 还没执行完，Cancel 就先到了，业务代码要能判断并跳过未发生的操作。这三个问题处理不好，TCC 比 AT 更容易出事故。

TCC 的优点是不依赖数据库的全局锁，性能比 AT 更高，适用于对一致性要求严苛、愿意为每段业务付出编码成本的场景。它像一场精心排练过的彩排——每一次试灯、试音都留下记录，最终要么正式上演，要么原样撤场。

SAGA模式

有时候大型演唱会要演一整个系列：明天是爵士专场，后天是摇滚专场，大后天是民谣专场。每个专场之间是串联关系，由总控台按照节目单一个一个往下走。如果中间某个专场临时取消了，总控台不会把已经演完的专场再演一遍，而是倒着把前面那些专场的场次依次“退款”给观众。这就是 SAGA 模式：用状态机编排，按顺序执行，失败则反向补偿。

SAGA 模式把一个长事务拆分成多个本地事务，每个本地事务对应一个状态节点。正向补偿就是按照编排顺序依次执行各个子事务，每个子事务执行完就提交并记录执行状态；反向补偿是当某个子事务失败时，从不成功的节点开始，逆序执行前面所有子事务的补偿动作。比如订机票、订酒店、订车三个步骤，酒店失败了，就依次取消机票和之前的其他预订。

SAGA 的核心是状态机编排，即每个全局事务都有一个状态机，记录了当前执行到第几个子事务、每个子事务是成功还是失败。与 TCC 相比，SAGA 不需要 Try 阶段，业务代码里不需要写预占资源的逻辑，因此无侵入性更好。但 SAGA 有一个先天弱点：子事务提交后的中间状态对其他事务可见，如果中间状态被读走了而后续又回滚，就可能产生脏读。

SAGA 适合长事务、多服务、对实时一致性要求不苛刻的场景。它像一场多场次的系列演出，总控台靠清晰的节目单和退票规则，把复杂的流程打理得井井有条。

事务流程

现在把整场演唱会从头到尾捋一遍。执行导演 TM 在演出开始前对总控台 TC 说：“启动全局档期，编号 TX-001。”TC 在调度表上登记这个档期，生成全局事务 ID，并把这个 ID 告诉所有工作小组——这是全局开启。

接着，各组组长 RM 领到任务后，开始干活。每完成一项本地任务，RM 就拿着全局事务 ID 向 TC 报告“我是灯光组，我的分支业务 id=branch-1，状态 OK”，TC 在调度表里把该分支记为“已注册”——这是分支注册。所有活都干完后，RM 把“成功/失败”的结果上报给 TC。

最后是决策阶段。如果所有 RM 都报告成功，TM 就对 TC 下达“全局提交”指令，TC 通知每个 RM 把快照清理掉，锁释放，一场演出完美收官；只要有一个 RM 报告失败，TM 就下达“全局回滚”指令，TC 通知每个 RM 用 undo_log 中的快照恢复数据，再释放全局锁，舞台重新回到演出前的状态。

从筹备到收工，每一个环节都环环相扣。理解了这条流程，你就能清楚地看懂 Seata 在报错日志里到底发生在哪一步——是全局没开启、分支没注册，还是回滚指令没送达。

应用实践

再完美的编排方案，落到真实舞台上都会遇到各种意外。Seata 在实践中最重要的第一步是配置部署：TC 需要作为一个独立服务部署（TCServer），客户端通过配置文件指定 TC 的地址；数据库里要建好 undo_log 表并初始化 AT 模式所需的表结构；file.conf 和 registry.conf 两个配置文件决定了事务日志存储方式和注册中心类型。

第二步是高并发优化。AT 模式虽然业务入侵小，但全局锁会让跨行更新变成串行，高并发下吞吐量会明显下滑。常用的优化手段包括：尽量缩小事务范围，把无关读操作移出全局事务；用 TCC 替换热点账户的 AT 模式；对热点数据做分片，避免所有请求都锁同一行。

第三步是踩坑经验。最常见的坑有：undo_log 表和数据表不在同一数据库导致回滚失败；服务重启后 TC 出现孤儿事务；超时时间设置过短导致长事务被误杀；以及回滚 SQL 生成失败（比如使用了不支持的类型或函数）。这些坑大多要靠配置检查、日志分析和压测来提前规避。最终目标只有一个——在高并发微服务场景下保证数据的最终一致性：允许短暂的不一致，但最终要对账收货。

实践出真知。演唱会办得越多，对现场的突发状况就越有预判。Seata 的落地同样如此：配置、优化、踩坑三轮打磨之后，分布式事务才能在高并发环境下稳稳兜住数据的底线。

---

AI 应用场景

Python 演示

class ATModeSimulator:    """极简版 AT 模式：模拟 Seata 的一阶段执行 + 二阶段提交/回滚"""     def __init__(self):        # 两张"账本"（全局数据表）        self.data = {"account_a": 1000.0, "account_b": 1000.0}        # 快照日志：记录每个分支事务修改前的镜像        self.undo_log = []     def branch_exec(self, target, delta):        """一阶段：执行本地 SQL，同时把旧值存入 undo_log 快照"""        if target not in self.data:            raise KeyError("目标账户不存在: %s" % target)        old_value = self.data[target]        new_value = old_value + delta        if new_value < 0:            raise ValueError("余额不足，写入失败")        self.data[target] = new_value        self.undo_log.append((target, old_value))        print("[RM] 更新 %s: %.2f -> %.2f，已记录快照" % (target, old_value, new_value))        return True     def commit(self):        """二阶段提交：删除快照，释放行锁"""        self.undo_log.clear()        print("[TC] 全局提交成功，快照已清理")     def rollback(self):        """二阶段回滚：按反顺序恢复旧值"""        while self.undo_log:            target, old_value = self.undo_log.pop()            self.data[target] = old_value            print("[TC] 回滚 %s 至 %.2f" % (target, old_value))        print("[TC] 全局回滚完成")  def main():    at = ATModeSimulator()    print("初始账本:", at.data)    try:        at.branch_exec("account_a", -300.0)   # A 扣款        at.branch_exec("account_b", 300.0)    # B 入账        # 模拟第二步失败：B 入账失败，触发全局回滚        at.branch_exec("account_b", -99999.0)        at.commit()  # 全部成功才提交    except ValueError as exc:        print("[TM] 捕获异常:", exc)        at.rollback()  # 回滚    print("最终账本:", at.data)  if __name__ == "__main__":    main()

1. class ATModeSimulator:定义 AT 模式模拟器，对应 Seata 中客户端侧对分支事务的管理能力。
2. self.undo_log = []快照日志，模拟 Seata 的 undo_log 表，记录每个分支修改前的旧值。
3. old_value = self.data[target]在执行 SQL 修改前先读旧值，这是生成回滚 SQL 的基础。
4. self.undo_log.append((target, old_value))把旧值追加到快照栈，模拟 AT 模式的 before image 记录过程。
5. def rollback(self):二阶段回滚：从栈尾开始 pop，逆序遍历快照，正好对应 Seata 倒序生成回滚 SQL 的策略。
6. while self.undo_log:循环直到快照栈为空，模拟 TC 通知 RM 逐个分支执行回滚。

常见误区

面试题