目录
引言
在单体应用架构中，数据库事务往往依靠 ACID 原则即可保障一致性。然而，随着微服务和分布式架构的普及，业务操作往往需要跨多个服务与数据库才能完成，传统的本地事务已难以满足需求。
例如在电商场景中，一个下单操作涉及订单创建、库存扣减、账户扣款三个环节。如果这些环节分散在不同的服务和数据库中，我们就必须解决分布式事务问题，保证“要么全部成功，要么全部失败”的业务原子性。
一、分布式事务的理论基础
1. CAP 定理
Eric Brewer 在 1998 年提出的 CAP 定理表明：在分布式系统中，一致性 (Consistency)、可用性 (Availability)、分区容错性 (Partition tolerance) 三者不可同时满足。由于网络分区不可避免，系统往往需要在一致性与可用性之间进行权衡。
2. BASE 理论
BASE 理论是对 CAP 的一种折中思路：
基本可用 (Basically Available)：系统在出现故障时仍能保持核心可用性。
软状态 (Soft State)：允许短暂的不一致状态存在。
最终一致性 (Eventually Consistent)：在一定时间后达到数据一致。
3. 分布式事务思路
基于 CAP 与 BASE 理论，常见的事务处理模式有：
AP 模式：允许各子事务独立执行，先出现不一致，再通过补偿手段恢复，追求最终一致性。
CP 模式：子事务执行后互相等待，同时提交或回滚，追求强一致性，但降低可用性。
二、初识 Seata
Seata 是由蚂蚁金服与阿里巴巴在 2019 年联合开源的分布式事务解决方案。它提供一站式的高性能事务服务，核心角色包括：
TC（事务协调者）：维护全局和分支事务状态，决定提交或回滚。
TM（事务管理器）：定义事务范围，发起、提交或回滚全局事务。
RM（资源管理器）：管理资源并向 TC 报告分支事务状态。
Seata 提供四种事务模式：
XA 模式：强一致性，两阶段提交，性能相对较低。
TCC 模式：需要业务代码配合，最终一致性。
AT 模式：默认模式，无业务侵入，性能优于 XA。
SAGA 模式：适合长事务场景，通过补偿操作实现一致性。
三、Seata 实战：事务模式解析
1. XA 模式
XA 模式遵循 X/Open 定义的 DTP 标准，核心思想是两阶段提交：
阶段一：TC 通知参与者执行本地事务并上报结果，但不提交，保持锁。
阶段二：如果所有分支成功，提交事务；若有失败，回滚事务。
优点：强一致性，支持主流数据库，零代码侵入。
缺点：阶段一锁定资源，性能差；依赖数据库实现事务。
实现步骤：
在 application.yml 配置 Seata 事务模式为 XA。
在业务入口方法上添加 @GlobalTransactional 注解。
重启服务后即可实现跨服务的强一致事务。
2. AT 模式
AT 模式同样是两阶段事务模型，但优化了资源锁定问题：
阶段一：直接提交事务，记录 undo_log 快照，并上报状态。
阶段二提交：删除快照；
阶段二回滚：根据快照恢复数据。
AT vs XA：
XA：阶段一不提交，锁定资源；
AT：阶段一直接提交，依赖快照回滚；
XA：强一致；AT：最终一致。
优点：
一阶段完成后释放资源，性能好。
无代码侵入，框架自动处理回滚。
缺点：
只能保证最终一致性。
框架生成快照会有性能开销。
实现步骤：
导入 lock_table 和 undo_log 表。
配置 application.yml 使用 AT 模式。
重启服务后即可完成自动回滚与提交。
四、总结
分布式事务的核心挑战在于如何在 CAP 理论约束下平衡一致性与可用性。Seata 作为一站式解决方案，提供了多种模式，帮助开发者根据业务需求选择合适的策略：
强一致场景：选择 XA。
高性能、低侵入：选择 AT。
需要业务补偿：选择 TCC 或 SAGA。
在实际开发中，推荐优先考虑 AT 模式，既能保证最终一致性，又能在性能与易用性之间取得平衡。对于金融、支付类场景，则可采用 XA 或 TCC 来保障关键数据的强一致性。