4. Saga事务协调器架构：协调器角色、状态机模型、事件驱动与命令驱动的区别
Saga事务协调器是分布式事务的核心控制组件，负责编排多个本地事务的执行顺序、处理补偿逻辑以及维护全局事务状态。在压测场景中，协调器的架构设计直接影响数据传输效率、故障恢复速度和吞吐量上限。本节从协调器角色、状态机模型以及事件驱动与命令驱动的对比三个维度展开分析。
4.1 协调器角色与职责
Saga协调器在分布式事务中承担以下关键角色：
- 事务编排者：定义并执行Saga事务的步骤序列，包括正向事务（T1, T2, …, Tn）和对应的补偿事务（C1, C2, …, Cn）。
- 状态管理者：维护每个Saga实例的当前状态，记录已完成的步骤、失败步骤以及待执行的补偿操作。
- 故障恢复者：在节点宕机或网络分区后，从持久化存储中恢复Saga状态，继续执行未完成的事务或触发补偿。
- 数据路由者：将事务上下文（如全局事务ID、步骤ID、业务载荷）传递给参与方服务，并收集执行结果。
- 超时监控者：为每个步骤设置超时阈值，超时后自动触发重试或补偿流程。
压测关注点：协调器的角色决定了其CPU、内存和网络I/O消耗模式。在压测中需重点监控协调器的状态持久化延迟、上下文传递开销以及超时检测的精度。
4.2 状态机模型
Saga协调器内部通常采用有限状态机（FSM）来管理事务生命周期。每个Saga实例在状态机中流转，状态迁移由步骤执行结果或外部事件触发。
以下为Saga事务的核心状态定义：
| 状态 | 含义 | 触发条件 |
|---|---|---|
| INITIATED | 事务已创建，尚未执行任何步骤 | 客户端发起Saga请求 |
| STEP_EXECUTING | 当前正向步骤正在执行 | 协调器发送执行命令 |
| STEP_SUCCEEDED | 当前步骤执行成功 | 参与方返回成功响应 |
| STEP_FAILED | 当前步骤执行失败 | 参与方返回失败或超时 |
| COMPENSATING | 正在执行补偿事务 | 步骤失败或业务异常 |
| COMPENSATED | 所有补偿事务执行完毕 | 补偿步骤全部完成 |
| COMPLETED | 所有正向步骤执行成功 | 最后一步成功 |
| ABORTED | 事务异常终止，无法补偿 | 补偿失败或系统崩溃 |
状态机模型在压测中的意义：
- 状态迁移路径决定了协调器的逻辑分支数量，影响CPU指令缓存命中率。
- 状态持久化（如写入数据库或消息队列）是压测中的关键瓶颈点。
- 并发Saga实例的状态管理需要高效的内存数据结构（如哈希表+跳表）。
压测建议：在压测脚本中模拟不同状态迁移路径（正常完成、单步失败、多步补偿、超时重试），以覆盖协调器状态机的所有分支。
4.3 事件驱动与命令驱动的区别
Saga协调器的通信模式分为事件驱动和命令驱动两种。两者在数据传输方式、耦合度和压测表现上存在显著差异。
4.3.1 事件驱动模式
协调器发布事件（如“订单已创建”“库存已扣减”），参与方订阅感兴趣的事件并自主执行后续操作。协调器不直接调用参与方，而是通过事件总线（如Kafka、RabbitMQ）异步传递消息。
- 优点：松耦合、高扩展性、支持广播。
- 缺点：事件顺序难以保证、调试困难、补偿逻辑复杂。
- 压测特征：吞吐量受限于事件总线的分区数和消费组延迟；需要关注事件重复消费和幂等性。
4.3.2 命令驱动模式
协调器直接向参与方发送命令（如“扣减库存”“创建订单”），并等待同步或异步响应。协调器控制执行顺序，参与方被动执行。
- 优点：执行顺序可控、补偿逻辑清晰、易于调试。
- 缺点：协调器成为单点瓶颈、耦合度高、扩展性受限。
- 压测特征：协调器的连接池大小、超时配置和线程模型直接影响最大并发数。
4.3.3 对比表格
| 维度 | 事件驱动 | 命令驱动 |
|---|---|---|
| 通信方式 | 异步事件发布/订阅 | 同步或异步命令调用 |
| 协调器负载 | 低（仅发布事件） | 高（管理所有调用） |
| 数据传递 | 事件载荷包含完整上下文 | 命令参数按需传递 |
| 顺序保证 | 依赖事件总线分区 | 协调器严格排序 |
| 补偿触发 | 由补偿事件驱动 | 协调器主动调用补偿 |
| 压测瓶颈 | 事件总线吞吐、消费延迟 | 协调器线程池、连接池 |
| 典型场景 | 跨团队、跨语言、高并发 | 内部服务、强一致性要求 |
压测陷阱：事件驱动模式下，如果事件总线出现背压（backpressure），协调器发布事件的速度会下降，导致Saga事务堆积。命令驱动模式下，协调器线程池耗尽会导致请求排队，压测时需区分“协调器瓶颈”和“参与方瓶颈”。
4.4 Saga协调器架构图
下图展示了Saga协调器在事件驱动模式下的核心架构，包含协调器内部状态机、事件总线以及参与方服务的交互关系。
4.5 命令驱动模式架构图
下图展示命令驱动模式下协调器与参与方的直接交互关系，强调同步调用链和补偿触发路径。
4.6 压测场景设计建议
基于协调器架构的差异，压测场景应覆盖以下关键路径：
- 正常路径压测：模拟所有步骤成功完成，验证协调器状态机从INITIATED到COMPLETED的完整流转，测量吞吐量和平均延迟。
- 单步失败补偿路径：在中间步骤注入失败，触发补偿流程，验证补偿事务的执行顺序和幂等性。
- 超时重试路径：设置短超时时间，模拟参与方响应超时，验证协调器的超时检测和重试机制。
- 并发Saga实例压测：同时启动大量Saga事务，观察协调器状态存储的写入压力、线程池竞争以及事件总线的积压情况。
- 故障恢复压测：在压测过程中kill协调器进程，验证从持久化存储恢复状态后能否正确继续或补偿未完成的事务。
压测指标：协调器CPU使用率、状态持久化P99延迟、事件总线消息积压数、线程池活跃线程数、补偿事务成功率。