分布式事务四大模式深度解析：用"订餐系统"看透AT/XA/TCC/Saga
一、互联网典型场景中的事务挑战
在电商秒杀场景中，用户支付成功后需要同时完成：订单状态更新（订单服务）、库存扣减（库存服务）、积分增加（积分服务）。这三个操作必须保持原子性，这正是分布式事务要解决的核心问题。
二、四大模式核心定义与比喻解析
1. XA协议：餐厅订位模式
严格定义：基于两阶段提交（2PC）的规范，依赖数据库原生支持，通过事务管理器协调多个资源管理器。
比喻：就像预定米其林餐厅，需要：
- 电话确认所有分店都有空位（Prepare）
- 收到所有确认后正式预定（Commit）
时序图：
[TM] [RM1] [RM2]
|--prepare----->| |
| |--prepare---->|
|<-all-ok-------| |
|---commit----->| |
| |---commit---->|
2. AT模式：自动订座系统
严格定义：Seata的自动补偿模式，通过解析SQL自动生成回滚日志，实现业务无侵入的事务管理。
自动性体现：
// 原始业务代码
@GlobalTransactional
public void purchase() {
orderService.create();
storageService.deduct();
pointsService.add();
}
// Seata自动生成：
// 1. 解析SQL生成before image
// 2. 执行后生成after image
// 3. 注册undo_log到TC
比喻：就像智能订座系统自动记录每个步骤，当某家分店订满时，系统自动取消其他预定。
3. TCC模式：分阶段确认订单
严格定义：Try-Confirm-Cancel三阶段模型，需要业务显式实现资源预留和补偿逻辑。
代码结构：
public interface TccService {
@TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
boolean tryDeduct(BusinessActionContext context, int count);
boolean confirm(BusinessActionContext context);
boolean cancel(BusinessActionContext context);
}
比喻：网购商品时：
- Try：锁定库存（不实际扣减）
- Confirm：支付成功后正式扣减
- Cancel：支付失败释放锁定
4. Saga模式：旅行计划编排
严格定义：Saga模式是一种用于处理长事务的解决方案，它通过正向服务调用和补偿服务调用，保证了最终的一致性。在分布式系统中，Saga模式常用于拆分长事务成多个短事务，并通过补偿机制处理失败，确保系统整体的一致性和可靠性。
实现方式对比：
| 编排式 Saga | 协同式 Saga | |
|---|---|---|
| 控制中心 | 无中心协调器 | 有状态机引擎 |
| 复杂度 | 服务间耦合度高 | 集中管理流程 |
| 典型实现 | 服务自己触发补偿 | 通过状态机配置 |
比喻：规划欧洲旅行：
-
正向操作：订机票→订酒店→安排租车→规划景点。
-
补偿操作：如果某一步骤失败，需要进行补偿，按照反向的顺序操作。
- 例如：如果租车失败，先取消酒店预订，再取消机票。
编排式 Saga
在编排式Saga中，每个服务负责自己的操作以及失败时的补偿。例如，在旅行计划中，假设“机票预订”服务成功后，它会调用“酒店预订”服务，并且“酒店预订”服务调用“租车”服务。若“租车”失败，服务需要触发“酒店预订”的补偿操作（如取消酒店预订）并进一步触发“机票预订”的补偿操作。
优点：每个服务相对独立，灵活性高。 缺点：服务之间的耦合度较高，维护和扩展可能较为困难。
协同式 Saga
在协同式Saga中，通过一个中心的状态机引擎来协调各个服务的流程和补偿操作。状态机引擎负责处理各个步骤的执行顺序，记录当前的事务状态，并确保每个步骤都能按预期完成。如果某个步骤失败，状态机会自动根据配置的补偿逻辑进行操作。
优点：流程管理集中，能够更好地进行监控和管理。 缺点：依赖中心化的协调器，可能导致扩展性和灵活性的问题。
总结：
- 编排式Saga的设计更加灵活，但服务间耦合较高；而协同式Saga则通过状态机进行流程管理，适用于需要集中管理事务流程的场景。
- 选择哪种方式需要根据具体场景的需求来确定，考虑到系统的复杂度、扩展性以及维护成本等因素。
