Saga 事务分类 (Classification of SAGA transactions)
根据事务的运行时行为与最终结果，在使用 Saga 设计模式时，我们主要可以识别出 3 种典型的事务执行场景：
-
完全成功事务 (Successful transactions)
-
补偿成功事务 (Compensating/Revert success transactions)
-
补偿失败事务 (Compensating/Revert failed transactions)
完全成功事务 (Primary Execution Success Transactions)
GET_USER_DETAIL 不被视为原子事务 (Atomic Transaction)。它仅是一个获取用户信息的只读查询操作。详情请参阅查询操作说明。
|
在上图中，业务流程涉及 4 个微服务并包含 4 次执行（其中 3 个为写入型原子事务）。 整个业务事务（Business Transaction）在成功执行完第 4 个原子步骤后宣告完成。 当所有正向主执行逻辑全部按预期成功执行时，这类事务被称为*完全成功事务 (Successful transactions)*。
完全成功事务的架构摘要图如下所示：
补偿成功事务 (Compensating Success Transaction)
在该场景中，当执行到支付扣款步骤 (MAKE_PAYMENT) 时发生了异常。
正向主执行流程随即因错误中断，Saga 引擎立即触发逆向补偿流程，按反向顺序撤销此前所有已经成功执行的步骤。
最终，逆向补偿流程全部顺利执行完毕。
从业务视角来看，这虽然是一笔失败的业务操作；但从 Saga 架构与数据一致性的视角来看，它属于架构上的成功事务。 因为系统通过对先前已提交的局部事务进行精准补偿，成功维护了分布式环境下的最终一致性 (Eventual Consistency)，没有任何脏数据残留。
补偿成功事务的架构摘要图如下所示：
补偿失败事务 (Compensating Failed Transaction)
在该场景中，正向执行到支付扣款 (MAKE_PAYMENT) 时发生了异常。
正向流程终止并启动逆向补偿流程以回滚前面的操作。
然而，在执行取消订单 (CANCEL_ORDER) 的补偿逻辑时，补偿动作本身不幸发生了故障。
| 此场景代表了分布式系统中的理论边缘情况 (Edge Case)。开发者应实现健全的错误处理与防错设计，最大限度避免补偿事务本身的业务失败。 补偿事务必须严格保持幂等性 (Idempotency)，且理论上仅应因瞬时基础设施故障（如资源不可用问题 / Resource Unavailability）而失败。 当遭遇下游服务暂时不可用或网络抖动时，应结合指数退避重试机制 (Exponential Backoff Retry) 与断路器 (Circuit Breakers)，确保在基础设施恢复后最终达成一致性。 |
| 不必担心如何手动处理这些复杂的异常状态。 StackSaga 提供了开箱即用的重试协调机制与隔离存储，使您可以轻松管理这些异常情况。 |
补偿失败事务的架构摘要图如下所示：
