详解Seata的核心组件TC、TM、RM

目录

1. Transaction Coordinator (TC) - 事务协调器

1.1 核心职责

1.2 工作原理

1.3 高可用设计

2. Transaction Manager (TM) - 事务管理器

2.1 核心职责

2.2 工作流程

2.3 关键特性

3. Resource Manager (RM) - 资源管理器

3.1 核心职责

3.2 AT模式下的特殊职责

3.3 重要机制

 4. 三组件协作流程详解

阶段1：全局事务开始

阶段2：分支事务注册

阶段3：全局事务提交

阶段4：分支事务提交（两阶段提交）

4.1（Phase 1）：

4.2（Phase 2）：

阶段5：完成通知

5. 关键点解析

6. 异常处理机制

7. 典型场景示例

---

1. Transaction Coordinator (TC) - 事务协调器

1.1 核心职责

TC 是 Seata 的核心服务器组件，主要负责：

• 全局事务管理：维护全局事务的生命周期（begin, commit, rollback）。

• 分支事务协调：协调所有参与服务的分支事务状态。

• 事务状态持久化：存储全局事务和分支事务的状态信息。

• 故障恢复：在系统崩溃后恢复事务状态。

1.2 工作原理

• 事务注册：接收TM发起的全局事务注册请求。

• 分支注册：处理RM发来的分支事务注册请求。

• 状态维护：

  • 记录全局事务状态（Begin, Committing, Commit-Retrying, Rollbacking, Rollback-Retrying, Timeout-Rollbacking, Timeout-Rollback-Retrying, AsyncCommitting）

  • 记录分支事务状态（Registered, PhaseOne_Done, PhaseOne_Failed, PhaseOne_Timeout, PhaseTwo_Committed, PhaseTwo_CommitFailed_Retryable, PhaseTwo_Rollbacked, PhaseTwo_RollbackFailed_Retryable）

• 最终决议：决定全局事务是提交还是回滚。

1.3 高可用设计

• 集群部署：支持多TC节点组成集群。

• 存储后端：支持文件、DB、Redis等多种存储模式。

• 心跳检测：定期检测RM/TM连接状态。

2. Transaction Manager (TM) - 事务管理器

2.1 核心职责

TM 是客户端组件，主要负责：

• 全局事务界定：定义事务边界（@GlobalTransactional）。

• 事务发起：向TC发起全局事务begin/commit/rollback请求。

• 超时控制：设置全局事务超时时间。

• 异常处理：捕获业务异常并触发回滚。

2.2 工作流程

@GlobalTransactional(timeoutMills = 60000, name = "myTx")
public void businessMethod() {// 1. 向TC注册全局事务(xid生成)// 2. 执行业务逻辑// 3. 出现异常时向TC发送rollback请求// 4. 成功时向TC发送commit请求
}

2.3 关键特性

• 声明式事务：通过注解方式定义事务。

• 超时机制：防止事务长时间悬挂。

• 异常传播：支持不同异常类型的传播行为配置。

3. Resource Manager (RM) - 资源管理器

3.1 核心职责

RM 是资源管理组件，主要负责：

• 分支事务注册：向TC注册分支事务。

• 本地资源管理：管理数据库连接等本地资源。

• 事务报告：向TC报告分支事务状态。

• 补偿操作：执行TC下发的commit/rollback指令。

3.2 AT模式下的特殊职责

• SQL解析：解析业务SQL生成undo log。

• 前置后置镜像：

  /* 前置镜像 */
  SELECT * FROM account WHERE id = 1 FOR UPDATE;/* 后置镜像 */
  UPDATE account SET balance = 100 WHERE id = 1;

• 补偿执行：根据undo log生成反向SQL。

3.3 重要机制

• 自动代理：自动拦截DML语句。

• 连接管理：维护与TC的长连接。

• 异步报告：批量报告分支事务状态提升性能。

 4. 三组件协作流程详解

阶段1：全局事务开始

TM -- begin --> TC

• TM发起请求：业务方法添加@GlobalTransactional注解后，TM会向TC发起"begin"请求。

• TC创建记录：TC在事务日志中创建全局事务记录，生成全局唯一的XID（事务ID）。

• 响应TM：TC返回XID给TM，这个XID将在整个分布式事务链路中传播。

阶段2：分支事务注册

        TC <-- register -- RM1TC             -- register --> RM2

• XID传播：TM将XID通过RPC上下文传递给服务A(RM1)和服务B(RM2)。

• RM1注册：

  • 服务A执行本地事务前，RM1向TC注册分支事务。

  • 携带信息：XID、分支事务ID、资源ID（如数据源）、锁资源（如表名+行键）。

• RM2注册：

  • 服务B执行本地事务前，RM2同样向TC注册分支事务。

• TC管理：TC在内存和存储中记录各分支事务的关联关系。

阶段3：全局事务提交

TM -- commit --> TC

• TM决策：当所有业务逻辑执行成功，TM向TC发起全局提交请求。

• TC状态转换：TC将全局事务状态从"Active"改为"Committing"。

阶段4：分支事务提交（两阶段提交）

  TC -- commit --> RM1TC           -- commit --> RM2

4.1（Phase 1）：

• 各RM在本地事务中：

  • 执行业务SQL。

  • 生成undo log（AT模式）或预留资源（TCC模式）。

  • 提交本地事务。

• 向TC报告"分支事务完成"。

4.2（Phase 2）：

1. 异步提交：

   • TC异步向各RM发送最终提交指令。

   • RM收到后删除undo log（AT模式）或确认资源（TCC模式）。

2. 结果收集：

   TC <-- done -- RM1
   TC <-- done -- RM2

阶段5：完成通知

TM <-- done -- TC

• TC确认所有分支事务完成后，通知TM最终结果。

• TM释放相关资源，结束事务上下文。

5. 关键点解析

• XID传播机制：

  • 通过ThreadLocal + 拦截器自动传播。

  • 跨服务时通过RPC框架的上下文传递（如Dubbo的RpcContext）。

• 分支注册时机：

  // RM在本地事务开启前注册分支
  Connection conn = dataSource.getConnection();
  // 隐式发生：conn.setAutoCommit(false)前会触发分支注册

• 两阶段提交优化：

  • 第一阶段就提交本地事务，释放连接资源。

  • 第二阶段只是清理工作，即使失败也有重试机制。

• 异常处理流程：

  • 任何步骤失败都会触发回滚。

  • TC会按照分支注册的逆序发起回滚。

  • RM根据undo log执行补偿操作。

6. 异常处理机制

三组件协同处理异常情况：

• TC宕机：依赖存储恢复事务状态。

• RM失联：TC会重试直到超时。

• TM超时：TC会自动触发超时回滚。

• 网络分区：通过心跳检测和超时机制处理。

7. 典型场景示例

电商下单场景：

• 订单服务（TM）开始全局事务。

• 依次调用：

  • 库存服务（RM1）扣减库存。

  • 账户服务（RM2）扣款。

  • 订单服务本地创建订单。

• 全部成功后全局提交。

• 任一服务失败则全局回滚。