TC、TM、RM如何协同解决分布式事务难题
在分布式系统架构中,事务管理一直是极具挑战性的技术难题。阿里巴巴开源的Seata框架通过其精妙的三组件架构——TC(Transaction Coordinator)、TM(Transaction Manager)和RM(Resource Manager),为分布式事务提供了优雅的解决方案。本文将深入剖析这三个核心组件的设计原理、协作机制及最佳实践。
一 Seata架构总览
三大组件的角色定位
组件 | 全称 | 角色类比 | 核心职责 |
---|---|---|---|
TC | Transaction Coordinator | 事务协调者 | 维护全局事务状态,协调分支事务的提交或回滚 |
TM | Transaction Manager | 事务发起者 | 定义事务边界,决定全局事务的最终状态(提交/回滚) |
RM | Resource Manager | 资源管理者 | 管理分支事务资源,向TC注册分支事务,并执行TC的提交或回滚指令 |
二 TC分布式事务的中枢神经系统
1. 核心架构设计
关键模块说明:
-
事务日志存储:记录全局事务和分支事务状态(支持DB、File、Redis)
-
锁管理器:维护全局行锁,防止脏写
-
协调引擎:处理两阶段提交/回滚逻辑
三 TM-全局事务的指挥官
1. 工作流程解析
四 RM-分支事务的执行者
1. 数据源代理机制
@Configuration
public class DataSourceConfig {@Bean@ConfigurationProperties(prefix = "spring.datasource")public DataSource druidDataSource() {return new DruidDataSource();}@Primary@Bean("dataSource")public DataProxy dataSourceProxy(DataSource dataSource) {return new DataSourceProxy(dataSource);}
}
2. undo_log表结构解析
CREATE TABLE `undo_log` (`id` bigint(20) NOT NULL AUTO_INCREMENT,`branch_id` bigint(20) NOT NULL,`xid` varchar(100) NOT NULL,`context` varchar(128) NOT NULL,`rollback_info` longblob NOT NULL,`log_status` int(11) NOT NULL,`log_created` datetime NOT NULL,`log_modified` datetime NOT NULL,PRIMARY KEY (`id`),UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
字段说明:
-
xid
:全局事务ID -
branch_id
:分支事务ID -
rollback_info
:回滚所需的SQL和前后镜像数据 -
log_status
:日志状态(0-正常,1-已回滚)