4. 补偿机制原理：Saga模式与TCC模式在审批流中的应用对比
在审批流超时自动补偿机制中，核心挑战在于如何保证跨多个审批节点、多个微服务的数据最终一致性。分布式事务领域的两大经典模式——Saga模式与TCC模式，为审批流补偿提供了截然不同的设计思路。本章将从原理、适用场景、优缺点及审批流适配性四个维度进行深度对比。
4.1 Saga模式：基于事件驱动的长活事务补偿
Saga模式将一个长事务拆分为多个本地事务，每个本地事务完成后发布事件，触发下一个本地事务。若某个节点失败，Saga会反向执行一系列补偿事务，回滚已提交的操作。
4.2 TCC模式：预留资源的两阶段补偿
TCC模式将每个服务操作拆分为三个阶段：Try（预留资源）、Confirm（确认执行）、Cancel（取消释放）。在审批流中，TCC模式要求在超时前先锁定资源，超时后根据状态决定是Confirm还是Cancel。
4.3 核心差异对比
| 对比维度 | Saga模式 | TCC模式 |
|---|---|---|
| 事务粒度 | 每个节点独立提交，无全局锁 | Try阶段锁定资源，粒度更细 |
| 补偿方式 | 反向执行补偿事务（Cancel/Undo） | 直接Cancel释放预留资源 |
| 一致性保证 | 最终一致性，补偿事务可能失败 | 强一致性（Try成功则Confirm必成功） |
| 性能开销 | 低，无资源锁定 | 中，Try阶段需锁定资源 |
| 实现复杂度 | 中，需定义补偿逻辑 | 高，需实现Try/Confirm/Cancel三接口 |
| 适用场景 | 长流程、异步、高吞吐 | 短流程、高一致性、资源敏感 |
4.4 审批流场景适配分析
审批流超时补偿的典型特征：
- 流程可能跨越数小时甚至数天，属于长事务
- 每个审批节点独立，不需要强锁定
- 超时后需要回滚已审批的节点，而非仅释放资源
- 补偿操作通常需要人工介入或异步通知
基于以上特征，Saga模式更适合审批流超时补偿，原因如下：
- 长事务支持：Saga不锁定资源，适合跨天审批流程
- 补偿灵活性：可针对每个节点定义不同的补偿逻辑（如撤回、通知、日志记录）
- 异步非阻塞：补偿事务异步执行，不影响其他审批流
- 容错性：即使补偿失败，也可通过重试或人工介入恢复
注意：TCC模式在审批流中仅适用于资源敏感场景（如预算锁定、库存预留），且要求Try阶段能快速完成。对于纯审批流转（无资源锁定），TCC的Try阶段反而增加了不必要的复杂度。
4.5 混合策略：Saga + TCC 组合模式
在实际企业系统中，审批流往往混合使用两种模式：
| 审批节点类型 | 推荐模式 | 原因 |
|---|---|---|
| 纯审批流转（无资源操作） | Saga | 低开销，补偿灵活 |
| 涉及预算锁定 | TCC | 保证预算一致性 |
| 涉及库存预留 | TCC | 防止超卖 |
| 涉及外部系统调用 | Saga + 重试 | 外部系统不支持TCC |
最佳实践：在审批流引擎中，将Saga作为默认补偿模式，对资源敏感节点叠加TCC的Try阶段。超时后，先执行TCC的Cancel释放资源，再执行Saga的补偿事务回滚审批状态。