【写给大佬的干货】Seata全解：TC、TM、RM角色拆解与核心部署实战指南-深圳市維司達科技有限公司

Seata（Simple Extensible Autonomous Transaction）是阿里巴巴开源的分布式事务解决方案。它的架构设计旨在通过最小化业务侵入来解决微服务架构下的数据一致性问题。

以下是对Seata框架三种角色以及部署方式的详细解析：

一、Seata框架的三种角色

Seata 的架构模型主要由TC（事务协调者）、TM（事务管理器）和RM（资源管理器）这三个核心角色组成。这三个角色分别承担了分布式事务生命周期中的不同职责。

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

定位：Server端，独立部署。
职责：
- 状态维护：负责维护全局事务和分支事务的状态（如Begin、PhaseOne_Commit、PhaseOne_Rollback等）。
- 事务决策：负责发起全局事务的提交（Commit）或回滚（Rollback）请求。
- 状态汇总：收集所有分支事务的状态（Commit/Rollback），决定全局事务的最终结果。
- 数据持久化：将事务状态写入事务日志表（global_table和branch_table），用于事务的恢复和补偿。

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

定位：Client端，通常由发起全局事务的业务服务扮演。
职责：
- 事务边界：负责开启、提交或回滚全局事务（对应@GlobalTransactional注解）。
- 业务控制：在业务代码中调用TC，告知TC事务的开始或结束。
- 状态汇报：根据业务执行结果，向TC汇报是否需要提交或回滚全局事务。

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

定位：Client端，通常由涉及具体业务资源（如数据库）的微服务扮演。
职责：
- 分支事务：负责在本地创建分支事务，并向TC注册分支事务（branch_register）。
- 资源操作：执行实际的业务操作（如SQL更新）。
- 回滚/提交：接收TC的指令，执行分支事务的提交或回滚（如AT模式下回滚Undo Log）。
- 锁管理：在AT模式下，RM负责锁表（lock_table）的管理，防止脏写。

二、Seata的部署方式

Seata 的部署主要分为Server端（TC）的部署和Client端（TM/RM）的集成。以下是详细的部署步骤与方案：

1. 部署前的准备

环境要求：JDK 1.8+、Maven（用于构建）、MySQL/PostgreSQL/Redis（用于事务日志存储）。
网络要求：TC服务器需要能够被业务服务（TM/RM）访问到。

2. TC（Server端）的部署

TC是Seata的核心服务，需要单独部署。

方式一：本地/服务器部署
1. 下载与解压：从Seata官方GitHub或官网（https://seata.io ）下载对应版本的二进制压缩包（如seata-server-1.6.0）。
2. 配置文件：
  - registry.conf：配置服务注册中心（如Nacos、Zookeeper），用于TC向注册中心注册自己的服务地址。
  - file.conf：配置事务日志的存储模式（Store Mode）。
    - 推荐使用DB模式：在生产环境中，通常选择store.mode=db，并配置MySQL连接信息（store.db.datasource）。
    - 注意：如果是单机调试，可以使用file模式；但file模式不支持高可用集群。
  - application.yml：可选的Spring Boot风格配置文件，用于覆盖默认配置。
3. 初始化数据库：
  - 在MySQL中创建seata库。
  - 执行script目录下的SQL脚本（如db.sql），创建global_table、branch_table、lock_table、undo_log等表。
4. 启动服务：
  - 在Linux/Mac终端执行：sh ./bin/seata-server.sh。
  - 在Windows终端执行：bin\seata-server.bat。
  - 启动参数：
    - -h：指定服务注册到注册中心的IP（默认自动获取）。
    - -p：指定服务端口（默认8091）。
    - -m：指定事务日志存储模式（如db）。
  - 集群部署：如果需要高可用集群，只需在多台机器上部署TC服务，并确保它们都注册到同一个注册中心（如Nacos）。
方式二：容器化部署（Docker/Kubernetes）
- Docker：官方提供了seataio/seata-server镜像。可以通过docker run -d -p 8091:8091 -v /path/to/config:/seata-server/resources seataio/seata-server启动。
- Kubernetes：可以使用官方提供的Helm Chart或自定义YAML文件进行部署，建议通过ConfigMap注入registry.conf和file.conf，通过Secret注入数据库密码。

3. Client端（TM/RM）的集成

TC部署完成后，业务服务需要通过集成Seata Client来扮演TM和RM角色。

依赖引入：
- Spring Cloud Alibaba项目通常引入spring-cloud-starter-alibaba-seata。
- Spring Boot项目引入seata-spring-boot-starter。

核心配置（application.yml）：

spring:cloud:alibaba:seata:tx-service-group:my_test_tx_group# 事务组名称，TC通过此名称来区分不同业务service:vgroup-mapping:my_test_tx_group:default# 将事务组映射到默认的TC分组（default）grouplist:default:127.0.0.1:8091# 指定TC服务的地址（如果是集群模式，使用Nacos注册中心则无需手动指定）registry:type:nacosnacos:server-addr:127.0.0.1:8848# 注册中心地址（推荐使用Nacos）

业务代码：
- 在全局事务的入口方法上添加@GlobalTransactional注解，即可将当前服务扮演为TM。
- 使用Seata的DataSource代理（如DataSourceProxy），在底层扮演RM角色，负责捕获Undo Log（AT模式）或锁表（AT模式）。

三、核心注意事项

事务组（Transaction Group）：my_test_tx_group是业务服务的唯一标识，TC会根据这个标识来区分不同业务的事务日志。
存储模式选择：
- AT模式（默认）：依赖于数据库Undo Log（撤销日志），对业务代码侵入性最低。
- TCC模式：需要业务手动补偿，适用于对业务有严格控制的场景。
- SAGA模式：适用于长事务。
- XA模式：直接依赖底层资源的XA协议，适用于所有资源都支持XA的情况。
高可用：生产环境强烈建议使用Nacos/Zookeeper作为注册中心，并将TC部署为集群模式（多节点），以避免单点故障。