seata通过tc、tm、rm三角色协作与xid透传实现分布式事务统一管控，at模式下自动记录undo_log并执行两阶段提交/回滚，仅需注解+配置即可，无需手动写补偿代码。
Java 中用 Seata 解决分布式事务，核心是把跨服务的多个本地事务纳入一个全局事务统一管控，靠的是 TC（协调器）、TM（管理器）、RM（资源管理器）三者协作，配合 XID 透传和两阶段提交逻辑。不是写一堆补偿代码，而是通过少量配置 + 注解 + 框架自动拦截，让原本各自为政的数据库操作“步调一致”。
明确角色分工，先搭好基础设施
Seata 不是纯客户端库，它需要一个独立部署的 TC 服务（即 Seata Server），作为全局事务的“大脑”。业务应用则作为 Client，按角色接入：
- TC（Transaction Coordinator）：单独部署，维护所有全局事务状态，响应 TM 和 RM 的注册、提交、回滚请求；
- TM（Transaction Manager）：由发起全局事务的服务承担，比如订单服务中加 @GlobalTransactional 注解的方法，就自动成为 TM；
- RM（Resource Manager）：每个参与事务的数据访问服务都要集成，自动代理 JDBC 操作，记录 undo 日志、上报分支状态、执行二阶段动作。
选对模式，AT 模式最常用也最省心
Seata 提供 AT、TCC、Saga、XA 四种模式，Java 微服务项目首选 AT 模式，前提是使用 MySQL/Oracle/PostgreSQL 等支持本地事务的关系型数据库，并通过 JDBC 访问：
- 一阶段：业务 SQL 执行的同时，Seata 自动在同个本地事务里生成 undo_log 表记录反向操作，然后提交本地事务并释放数据库锁；
- 二阶段：若全局提交，TC 异步通知各 RM 清理 undo_log；若全局回滚，RM 根据 undo_log 自动执行补偿 SQL（比如把扣款金额加回去）；
- 无需改业务逻辑，不侵入 DAO 层，只要在入口方法加 @GlobalTransactional，框架自动织入事务上下文和回滚机制。
关键配置不能漏，XID 必须透传
分布式事务失效最常见的原因是 XID 断链——全局事务 ID 没能在服务调用链路中正确传递：
- Spring Cloud 项目需引入 seata-spring-cloud-starter-alibaba，它会自动将 XID 注入 Feign、Dubbo、OpenFeign 等远程调用的 header 或 attachment；
- 手动 HTTP 调用时，必须显式从当前上下文取出 XID（如 RootContext.getXID()），再放入请求头（如 “txid: xxx”），下游服务才能识别并绑定到自己的 RM 分支；
- 数据库连接池要配置为 Seata 兼容版本（如 Druid + seata-druid-adapter），否则 RM 无法拦截 SQL 并写 undo_log。
注意隔离性与读写约束
AT 模式默认全局读未提交（Read Uncommitted），可能读到未最终确认的数据。如需强读一致性：
- 对关键查询语句使用 SELECT FOR UPDATE，Seata 会代理该语句，申请全局锁，阻塞直到持有锁的事务结束，确保读到已提交结果；
- 避免在全局事务内做非事务性操作（如发 MQ、调外部 HTTP），这些不会被回滚，需额外设计补偿；
- 高并发下争抢同一行记录的全局锁可能导致超时回滚，可通过业务拆分、分库分表或调整锁等待策略缓解。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
