微服务架构拆分业务后，数据往往分散在不同服务、不同数据库中，跨服务业务流程很难依靠本地事务保障数据一致性，分布式事务问题随之凸显。Apache Seata 作为主流开源解决方案，专门面向微服务场景设计，提供标准化、轻量化的分布式事务管控能力，高效解决跨服务数据一致性难题。
Seata 是开源高性能分布式事务框架，核心目标是简化分布式事务开发成本，兼顾运行性能与易用性，统一治理微服务架构下各类跨库、跨服务事务，保障业务数据一致可靠。
Seata 内置四种成熟事务模式，可根据业务一致性要求、流程长短、性能需求灵活选用：
AT：自动事务模式，低侵入首选方案
TCC：手动三阶段事务，精细化业务管控
SAGA：长流程柔性事务，适配复杂长链路业务
XA：标准两阶段提交，兼容传统数据库事务规范
Seata 整体架构由三大核心角色协同完成全局事务管控，分工明确、各司其职：
事务协调者 TC：独立服务端组件，全局事务中枢，负责全局事务状态记录、分支事务调度、提交与回滚统筹
事务管理器 TM：嵌入业务服务客户端，负责开启全局事务、标记全局事务结束，向 TC 发起事务指令
资源管理器 RM：嵌入业务服务客户端，负责管理本地数据库资源、注册分支事务、监听 TC 指令执行分支提交或回滚
XA 是数据库层面通用分布式事务标准，严格遵循两阶段提交协议实现事务原子性。
准备阶段：所有事务参与者执行预提交操作，锁定业务数据资源，向协调者反馈预备状态
提交阶段：协调者收集全部参与者预备成功信号后，统一指令所有节点正式提交；任意节点预备失败，则统一指令全部节点执行事务回滚
该模式需要数据库原生支持 XA 协议，为保证强一致性通常需设置串行化隔离级别，会长期占用数据库连接与数据读写锁，极大降低系统并发吞吐量。
优点
协议标准化，通用兼容性强
业务代码零侵入，无需手动编写事务逻辑
缺点
事务阻塞时间长，整体运行性能偏低
极易引发数据库死锁问题
强依赖数据库原生 XA 能力
适用场景
金融核心账务、资金清算等对数据强一致性要求极高，可容忍低并发、低可用性的核心业务。
AT 是 Seata 默认主推的分布式事务模式，也是企业项目使用最广泛的方案，基于本地事务 + 快照日志实现分布式事务管控，完美规避 XA 长锁阻塞问题。核心原理分为两个阶段：
一阶段执行业务 SQL，自动生成数据前后镜像存入 undo_log 回滚日志，本地事务直接提交释放锁，不阻塞业务流程
二阶段由 TC 统一调度，全局事务成功则异步清理回滚日志；全局事务失败则依靠镜像日志自动反向执行 SQL 完成数据回滚
优点
业务代码几乎无侵入，接入简单、学习成本低
相比 XA 模式并发性能大幅提升
兼顾业务易用性与数据一致性
缺点
业务库必须提前创建 undo_log 日志表，依赖数据库本地事务
仅适配 JDBC 标准数据库访问方式，特殊 SQL 语法存在兼容限制
高并发热点数据场景下，全局锁会产生性能瓶颈
适用场景
绝大多数互联网通用业务，电商下单、订单流转、会员业务等日常微服务主流场景。
TCC 属于业务层手动实现的分布式事务模式，完全脱离数据库底层事务依赖，开发者需要手动定义三个固定阶段业务接口：
Try 尝试阶段：完成业务资源校验、资源预冻结、数据预预留，不执行正式业务提交
Confirm 确认阶段：所有分支 Try 阶段全部成功后，正式执行业务提交，确认资源生效
Cancel 取消阶段：任意分支 Try 阶段失败，触发全局回滚，释放已预留资源，撤销预操作
优点
事务管控粒度极高，业务灵活性极强
无数据库锁竞争，并发性能优秀
不依赖数据库事务能力，适配异构数据源
缺点
业务代码侵入性极强，开发与维护成本高
必须手动处理幂等性、空回滚、事务悬挂等异常问题
仅能实现最终一致性，无法做到实时强一致
适用场景
异构数据源事务、第三方接口联动事务、需要高度自定义事务流程的特殊业务。
SAGA 专为超长链路分布式事务设计，核心思想是将一条完整长事务，拆分为多个独立可执行的本地子事务，同时为每一个正向子事务配置对应的反向补偿事务。执行逻辑：按顺序正向执行所有子事务，任意环节执行失败，自动逆向调用前置所有成功事务的补偿接口，完成整体业务回滚。
优点
支持超长时间跨服务事务流转，可实现异步化执行
拆分事务粒度灵活，长流程业务适配性好
无严格数据库事务约束，拓展性强
缺点
无法保障事务隔离性，易出现中间状态数据问题
业务侵入度高，需要编写大量补偿业务逻辑
异常场景流程复杂，排查难度大
适用场景
供应链长流程、订单履约全链路、异地多服务协同等耗时久、步骤多的长事务业务。
TM 开启全局事务，向 TC 申请生成唯一全局事务 ID
各个微服务 RM 拦截本地业务操作，注册分支事务并上报 TC
所有分支事务完成一阶段业务执行并提交本地事务
业务流程全部执行完毕后，TM 向 TC 发起全局事务结束指令
TC 汇总所有分支事务状态，判定全局事务提交或回滚
RM 接收 TC 指令，批量执行二阶段提交或自动回滚操作，完成全局事务闭环
结合前文 CAP 与 BASE 理论来看：
XA、AT 模式偏向遵循 CP 思想，优先保障数据一致性，牺牲部分并发可用性
TCC、SAGA 模式贴合 BASE 理论，放弃实时强一致，依靠补偿机制实现最终一致性，优先保障服务高可用，更适配互联网高并发业务架构。
