Saga 基础回顾：两种协调模式与事务协议对比
Saga 是一种长活事务（Long-Running Transaction, LRT）解决方案，将一个大事务拆分为多个本地事务（子事务），每个子事务都有对应的补偿操作。Saga 事务的核心在于协调模式的选择——编排（Choreography）与协同（Orchestration），二者在架构、耦合度、可观测性上存在本质差异。本节将系统回顾这两种模式，并与 TCC、2PC 进行横向对比，为后续压测场景中的链路追踪优化奠定基础。
2.1 编排模式（Choreography）
编排模式中，没有中央协调器。每个微服务在完成本地事务后，通过事件总线（如 Kafka、RabbitMQ）发布领域事件，下游服务监听并触发下一步操作。若某一步失败，由各服务自行发布补偿事件，形成“事件驱动的补偿链”。
核心特征：去中心化、事件驱动、服务间通过消息解耦。
适用场景：业务流程相对简单、服务数量少（通常 ≤ 5）、团队对事件驱动架构有成熟经验。编排模式在压测中容易产生“事件风暴”，链路追踪需要捕获跨服务的异步事件 ID。
2.2 协同模式（Orchestration）
协同模式引入一个中央协调器（Orchestrator），由它负责向各参与服务发送指令，并管理整个 Saga 的生命周期。协调器通常以状态机方式实现，记录每个步骤的执行状态，失败时按逆序调用补偿接口。
核心特征：集中控制、状态机驱动、补偿逻辑由协调器统一编排。
适用场景：业务流程复杂、服务数量多（≥ 5）、需要严格的可观测性和审计日志。协同模式在压测中协调器容易成为瓶颈，链路追踪需重点监控协调器的状态机转换延迟。
2.3 编排 vs 协同：关键对比
| 对比维度 | 编排模式（Choreography） | 协同模式（Orchestration） |
|---|---|---|
| 协调方式 | 事件驱动，无中心节点 | 中央协调器统一调度 |
| 服务耦合度 | 低，服务间通过事件解耦 | 中，服务仅与协调器交互 |
| 补偿逻辑 | 分散在各服务的事件处理器中 | 集中在协调器的状态机中 |
| 可观测性 | 困难，需追踪跨服务事件链 | 容易，协调器记录完整执行轨迹 |
| 压测瓶颈 | 事件总线吞吐量、消息顺序 | 协调器 CPU/内存、状态存储 |
| 链路追踪复杂度 | 高，需关联异步事件 ID | 中，以协调器 trace 为根 |
| 典型实现 | Axon、Eventuate Tram | Camunda、Temporal、Seata AT |
2.4 Saga 与 TCC、2PC 的协议对比
在分布式事务领域，Saga、TCC（Try-Confirm/Cancel）和 2PC（两阶段提交）是三种主流方案。它们在一致性保证、隔离性、性能开销上各有取舍。压测场景中，选择哪种协议直接决定了链路追踪的数据采集策略。
| 对比维度 | Saga | TCC | 2PC |
|---|---|---|---|
| 一致性模型 | 最终一致性 | 最终一致性 | 强一致性（ACID） |
| 隔离性 | 弱（需业务补偿） | 中（Try 阶段预留资源） | 强（全局锁） |
| 资源锁定 | 不锁定，提交后才释放 | Try 阶段锁定资源 | Prepare 阶段锁定资源 |
| 事务时长 | 长（秒级到分钟级） | 中（秒级） | 短（毫秒级） |
| 吞吐量 | 高 | 中 | 低（全局锁限制） |
| 实现复杂度 | 中（需设计补偿逻辑） | 高（需实现 Try/Confirm/Cancel） | 低（数据库原生支持） |
| 链路追踪关注点 | 事件链、补偿触发路径 | Try 阶段资源预留状态 | Prepare 阶段投票结果 |
| 压测典型瓶颈 | 事件总线积压、补偿风暴 | 资源预留超时、Cancel 回滚 | 协调者单点、锁等待 |
压测选型提示：若业务允许最终一致性且对吞吐量要求高（如订单、物流），优先选择 Saga；若需要较强的资源防冲突（如库存扣减），TCC 更合适；若必须强一致性且并发量低（如账户转账），2PC 仍可接受。链路追踪的数据传输优化策略将因协议不同而差异显著——Saga 需要追踪异步事件 ID 的传递，TCC 需要记录 Try 阶段的资源锁状态，2PC 则需要捕获 Prepare 阶段的投票超时。
2.5 压测视角下的关键差异总结
- 编排模式：压测时需模拟事件总线的背压场景，链路追踪必须支持跨线程/跨服务的 TraceId 传播，补偿事件可能引发“补偿风暴”，需设计采样策略。
- 协同模式：协调器是压测的单一瓶颈点，状态机的每次状态转换都应生成 Span，补偿路径的 Span 数量可能翻倍，需优化 Span 上报的批量大小。
- Saga vs TCC：TCC 的 Try 阶段会锁定资源，压测中更容易出现死锁或超时，链路追踪需额外记录资源锁的持有时间。
- Saga vs 2PC：2PC 的 Prepare 阶段需要所有参与者投票，压测中网络分区或慢节点会导致全局阻塞，链路追踪需快速定位“投票慢”的参与者。
课程后续方向：基于上述对比，第 3 章将深入 Saga 压测场景的链路追踪数据模型设计，重点解决异步事件链的 TraceId 传递与补偿路径的 Span 压缩问题。