分布式事务协调服务需明确tc、tm、rm三角色：sql server用msdtc作tc；seata需独立部署tc，tm/rm嵌入应用；mysql xa由应用层驱动协调；atomikos在spring boot中内嵌tc实现。

要配置分布式事务协调服务，关键在于明确三类核心角色的职责，并按需部署和联动。不同技术栈下角色命名略有差异，但逻辑一致：必须有协调者（tc）、发起者（tm）和执行者（rm），缺一不可。

SQL Server 环境：MSDTC 作为协调器

在 Windows + SQL Server 场景中，MSDTC（Microsoft Distributed Transaction Coordinator）天然承担协调器（TC）角色，无需单独安装新服务，但需正确启用和互通：

• 确保所有参与服务器上的 MSDTC 服务已启动，且登录账户为 NT Authority\NetworkService 或具备网络访问权限的域账户
• 打开“组件服务 → 计算机 → 我的电脑 → 属性 → MSDTC → 安全配置”，勾选：
  ✔ 网络 DTC 访问
  ✔ 允许远程客户端、允许远程管理
  ✔ 允许入站、允许出站
  ✔ 不要求进行验证（生产环境建议改用“仅限认证”）
• 防火墙开放 TCP 135 端口（RPC 终结点映射器），并为 %windir%\system32\msdtc.exe 添加入站规则
• 若涉及可用性组，SQL Server 2016 SP2+ 或 2017+ 才支持将每个数据库注册为独立资源管理器（RM），需在 AG 配置中启用分布式事务支持

Seata 架构：TC 独立部署，TM/RM 嵌入应用

在微服务场景（如 Spring Cloud + Seata），协调服务需显式部署 TC（Transaction Coordinator）节点，由 TM 和 RM 主动注册接入：

windows-healing-gateway

通过任务计划程序自动监控并自修复 Windows 上的 OpenClaw Gateway，具备 AI 诊断和 Telegram 报警功能。

下载

• TC（协调器）：独立 Java 进程，通过 Nacos/Eureka 注册发现；需配置 store.mode=db 并初始化 global_table、branch_table 等表；监听端口默认 8091
• TM（事务管理器）：嵌入在发起全局事务的服务中（如订单服务），通过 @GlobalTransactional 注解标识事务边界
• RM（资源管理器）：嵌入在每个参与事务的数据服务中（如库存、账户服务），自动代理数据源，拦截 SQL 并向 TC 注册分支事务
• 所有服务需统一配置事务分组名（如 my_test_tx_group），并在 Nacos 中与 TC 的集群名匹配

MySQL XA 场景：无中心协调器，依赖应用层驱动

MySQL 原生 XA 是对等式两阶段提交，不依赖外部协调服务，但要求应用层严格控制流程：

• 协调逻辑由应用程序（或 JDBC 驱动）承担，即应用本身临时充当 TM 角色
• 每个 MySQL 实例作为 RM，需设置 max_prepared_transactions > 0（如 100），否则无法持有 XA 事务状态
• 应用需按顺序执行：XA START → 多库操作 → XA END → XA PREPARE → 根据结果统一 XA COMMIT 或 XA ROLLBACK
• 悬挂事务可通过 XA RECOVER 查看，需人工干预或定时任务清理

Spring Boot 集成 Atomikos：内嵌协调器

适用于单体多数据源或轻量级分布式场景，Atomikos 在应用进程内实现 TC 功能：

• 引入 spring-boot-starter-jta-atomikos，禁用 Spring Boot 默认的 DataSource 自动配置
• 为每个数据源定义 XaDataSource（如 MysqlXADataSource），并配置唯一 unique-resource-name
• 声明 JtaTransactionManager Bean，绑定 Atomikos 事务服务实例
• 使用 @Transactional 即可触发跨数据源的两阶段提交，无需额外服务部署