当前位置：首页 > news >正文

理解分布式事务TC\TM\RM

news 2026/6/13 14:43:49

一、TC、TM、RM 核心定义 + 订单 / 账户服务精准角色划分

1. 三大核心角色（绝对核心，牢记）

TC（Transaction Coordinator）：事务协调者→ 独立部署的Seata Server 服务端，唯一的「总控中心」
- 职责：统一生成分支事务 ID（BID）、维护 XID 和 BID 的一对多绑定关系、存储所有全局 / 分支事务状态、接收 TM 的全局提交 / 回滚指令、向 RM 下达分支提交 / 回滚指令，不参与任何业务逻辑。
TM（Transaction Manager）：事务管理器→订单服务（order）就是唯一的 TM
- 职责：分布式事务的发起者 / 入口，在标注@GlobalTransactional的方法里本地生成全局事务 ID（XID）→ 把 XID 绑定到自己的线程上下文 → 向 TC注册这个 XID 的全局事务→ 执行业务（创建订单 + 远程调用扣钱）→ 业务执行完后，只携带 XID 向 TC 发起「全局提交 / 回滚」指令。
- 关键：TM只持有 XID，全程不碰 BID、不知道 BID 的存在。
RM（Resource Manager）：资源管理器→订单服务 + 账户服务（account）都是 RM（RM 是「干活的执行者」，只要操作数据库 / 资源的都是 RM）
- 订单服务（RM）：执行「创建订单」的本地数据库操作，是全局事务下的第一个分支；
- 账户服务（RM）：执行「扣钱」的本地数据库操作，是全局事务下的第二个分支；
- 职责：拿到 XID → 向 TC 注册分支事务、获取 TC 分配的 BID → 执行本地业务逻辑 → 等待 TC 的分支提交 / 回滚指令 → 执行最终的提交 / 回滚。
- 关键：RM持有 XID+BID，只和 TC 交互，和 TM 无直接指令交互。

✅ 二、订单 + 扣钱完整分布式事务执行流程（按你的场景，一步不差）

前提

order 和 account 都引入了 Seata 客户端、配置了 TC 地址；
order 有@GlobalTransactional，是 TM+RM；account 无注解，纯 RM；
所有 XID 的透传、绑定、分支注册，全是 Seata 自动做，业务代码无感知。

完整步骤

TM（order）生成 XID + 注册全局事务：执行@GlobalTransactional的创建订单方法，Seata 本地生成唯一 XID，绑定到 order 的线程上下文，然后向 TC 注册「这个 XID 的全局事务」，TC 记录这个 XID 的全局事务状态为「执行中」。
TM（order）作为 RM，执行本地分支：order 执行「创建订单」的 SQL，Seata 拦截 SQL，发现线程上下文有 XID → 自动向 TC 注册分支，TC 生成BID1并返回 → order 执行创建订单 + 生成 undo_log，完成第一个分支的预执行。
XID 自动透传至 account：order 远程调用 account 的扣钱接口，Seata 的 Feign 拦截器自动从线程上下文拿 XID，塞进请求头；account 收到请求后，Seata 的 MVC 拦截器自动从请求头提取 XID，绑定到 account 自己的线程上下文。
RM（account）注册分支 + 执行业务：account 执行「扣钱」的 SQL，Seata 拦截 SQL，发现线程上下文有 XID→ 判定自己是分布式事务的一员，自动向 TC 注册分支，TC 生成BID2并返回 → account 执行扣钱 + 生成 undo_log，完成第二个分支的预执行。✅ 核心判断逻辑：RM 只认「线程上下文 RootContext 里有没有有效 XID」，有就走分布式事务逻辑，没有就直接放行走普通本地事务。
TM（order）发起全局指令：order 的业务方法执行完毕（无异常 = 提交，有异常 = 回滚），只携带XID向 TC 发起「全局提交 / 回滚」请求，全程不带任何 BID。
TC 总控协调所有 RM：TC 拿到 XID 后，找到这个 XID 绑定的所有 BID（BID1+BID2），分别向 order、account 下发「分支提交 / 回滚」指令（指令里带 XID+BID）。
所有 RM 执行最终操作：order 和 account 收到 TC 的指令后，根据 XID+BID 执行最终的提交（删除 undo_log）或回滚（根据 undo_log 恢复数据），执行完后向 TC 汇报结果，TC 更新全局事务状态，整个分布式事务结束。

✅ 三、你问的 2 个核心安全问题（精准答案，无多余）

问题 1：万一有人往 context 里放一个混乱的无效 XID怎么办？

→完全无效，直接被拦截，Seata 有两层校验：

第一层：本地快速校验 XID 格式，混乱的字符串（比如abc@123）不符合 Seata 的 XID 格式规范，直接判定无效，跳过分布式事务逻辑，走普通本地事务；
第二层：就算格式像真的，向 TC 注册分支时，TC 里没有这个 XID 的全局事务记录，直接返回失败，RM 抛异常，分支注册失败，业务要么回滚要么走本地逻辑。

问题 2：万一有人往 context 里放一个真实有效的、但不是当前事务的 XID怎么办？

→能注册分支，但完全无影响，数据绝对安全，核心原因 3 个：

TC 只会给「处于执行中」的 XID 注册分支，若这个 XID 已经提交 / 回滚 / 超时，直接注册失败；
就算注册成功，这个错配的分支，只会收到「原 XID 对应的 TM」的指令，和当前事务毫无关系，当前事务的提交 / 回滚指令不会下发给它；
兜底：分支和业务是强绑定的，错配的分支执行的还是「当前扣钱 / 创建订单」的业务，就算被回滚，也只是当前业务执行失败，不会篡改任何其他业务的数据，数据一致性不受影响。