2. Saga核心原理：Saga的两种协调模式、补偿事务机制与状态机模型
Saga是一种用于管理分布式长事务的架构模式，通过将一个大事务拆分为多个本地事务，并引入补偿机制来保证最终一致性。理解Saga的核心原理，是进行链路追踪与故障定位的基础。本节将深入剖析Saga的两种协调模式、补偿事务机制以及状态机模型。
2.1 Saga的两种协调模式
Saga的协调模式决定了各参与服务如何通信以及如何控制事务流程。主要分为编排（Choreography）和协调（Orchestration）两种。
2.1.1 编排模式（Choreography）
在编排模式中，每个服务在完成本地事务后，会发布一个事件，其他服务监听该事件并触发下一步操作。没有中央协调器，所有服务通过事件总线进行异步协作。
- 优点：架构轻量，服务间解耦，适合简单、线性的业务流程。
- 缺点：流程隐式，难以追踪和调试；当服务数量增多时，事件循环和依赖关系变得复杂，容易形成“循环依赖”或“事件风暴”。
2.1.2 协调模式（Orchestration）
协调模式引入一个中央协调器（Orchestrator），负责管理整个Saga的执行流程。协调器向各个参与服务发送指令，执行本地事务或补偿事务，并根据执行结果决定下一步动作。
- 优点：流程显式，易于管理和监控；故障定位清晰，协调器是唯一的控制点。
- 缺点：协调器可能成为单点瓶颈，且增加了架构的复杂度。
压测场景建议： 在压测场景库中，协调模式更有利于故障定位。因为协调器会记录每一步的执行状态和耗时，压测时可以通过追踪协调器的日志和链路，快速定位是哪个服务节点出现性能瓶颈或异常。
2.2 补偿事务机制
补偿事务是Saga保证最终一致性的核心。当Saga中的某个本地事务执行失败时，系统需要回滚之前已成功执行的事务，这种回滚操作称为“补偿”。补偿事务在业务层面是“逆向操作”，而非数据库层面的回滚。
| 正向事务 | 补偿事务（逆向操作） | 说明 |
|---|---|---|
| 订单创建 | 订单取消 | 将订单状态标记为“已取消” |
| 库存扣减 | 库存回滚 | 将扣减的库存数量加回 |
| 账户扣款 | 账户退款 | 将扣款金额返还至用户账户 |
| 积分增加 | 积分扣回 | 扣除之前增加的积分 |
关键原则： 补偿事务必须是幂等的。在分布式系统中，网络超时或重试可能导致补偿请求被多次执行，幂等性确保多次执行补偿操作的结果与执行一次相同，避免数据不一致。
2.3 Saga状态机模型
Saga的执行过程可以抽象为一个有限状态机（FSM）。每个Saga实例都有一个明确的状态，状态转换由事件驱动。理解状态机模型是设计Saga链路追踪数据模型的基础。
一个典型的Saga状态机包含以下核心状态：
- Pending（待处理）：Saga实例已创建，但尚未开始执行。
- Running（运行中）：Saga正在按顺序执行本地事务。
- Completed（已完成）：所有本地事务均成功执行，Saga正常结束。
- Compensating（补偿中）：某个本地事务失败，Saga正在执行补偿事务。
- Compensated（已补偿）：所有补偿事务均成功执行，Saga回滚完成。
- Failed（失败）：补偿过程中也发生了无法恢复的错误，Saga进入最终失败状态。
压测场景库中的应用： 在压测场景库中，我们可以为每个Saga实例记录其状态机转换路径。例如，一个正常的Saga实例的状态路径为：
Pending → Running → Completed。而一个失败的实例路径可能为：Pending → Running → Compensating → Compensated。通过分析压测过程中大量Saga实例的状态分布，可以快速发现系统瓶颈或异常模式。