3. Saga 协调模式详解：编排模式与协调模式的架构对比
Saga 分布式事务的核心在于如何协调多个本地事务的提交与补偿。业界主要存在两种协调模式：编排模式（Choreography）与协调模式（Orchestration）。理解两者的架构差异，是设计高可用 Saga 系统的基础，也是后续排查超时与连接池故障的前提。
3.1 编排模式（Choreography）
编排模式是一种去中心化的协调方式。每个参与 Saga 的微服务在完成本地事务后，通过事件总线（如 Kafka、RabbitMQ）发布领域事件，其他服务监听并响应这些事件，从而形成一条事务链。没有中央协调器，服务之间通过事件驱动进行协作。
核心特征：去中心化、事件驱动、服务间松耦合、每个服务只关心与自己相关的事件。
编排模式工作流程示例
- 订单服务创建订单，发布“订单已创建”事件。
- 支付服务监听该事件，执行扣款，发布“支付成功”事件。
- 库存服务监听“支付成功”事件，执行扣减库存，发布“库存已扣减”事件。
- 若库存不足，库存服务发布“库存扣减失败”事件，支付服务和订单服务分别监听并执行补偿操作（退款、取消订单）。
故障排查要点：编排模式下，事件传递路径长，超时故障往往表现为“事件丢失”或“补偿事件未触发”。排查时需重点检查事件总线的消费延迟、消息积压以及每个服务的补偿监听器是否正常注册。
3.2 协调模式（Orchestration）
协调模式引入一个中央协调器（Orchestrator），负责管理整个 Saga 的执行流程。协调器向各个参与服务发送指令（如“执行支付”、“执行库存扣减”），并等待响应。根据响应结果，协调器决定下一步是继续执行还是触发补偿。协调器通常以状态机的方式实现。
核心特征：中心化控制、指令驱动、流程清晰、补偿逻辑集中管理。
协调模式工作流程示例
- Saga 协调器向订单服务发送“创建订单”指令。
- 订单服务执行成功，返回响应；协调器记录状态，向支付服务发送“执行支付”指令。
- 支付服务执行成功，返回响应；协调器向库存服务发送“扣减库存”指令。
- 若库存服务返回失败，协调器根据预定义的补偿流程，依次向支付服务发送“退款”指令、向订单服务发送“取消订单”指令。
故障排查要点：协调模式下，协调器是单点故障和性能瓶颈。排查超时问题时，应优先检查协调器的线程池是否耗尽、数据库连接池是否打满、以及状态机是否卡在某个中间状态。
3.3 架构对比分析
| 对比维度 | 编排模式（Choreography） | 协调模式（Orchestration） |
|---|---|---|
| 控制方式 | 去中心化，事件驱动 | 中心化，指令驱动 |
| 耦合度 | 服务间通过事件松耦合 | 服务与协调器耦合，服务间无直接依赖 |
| 流程复杂度 | 流程隐式，分散在多个事件处理器中 | 流程显式，集中在协调器状态机中 |
| 补偿管理 | 每个服务自行监听并执行补偿 | 协调器统一管理补偿指令 |
| 可观测性 | 较差，需要追踪事件链路 | 较好，协调器记录完整执行轨迹 |
| 单点风险 | 无单点，但事件总线可能成为瓶颈 | 协调器是单点，需高可用部署 |
| 典型超时场景 | 事件消费超时、补偿事件丢失 | 协调器指令超时、状态机卡死 |
| 适用场景 | 服务数量少、流程简单、团队自治度高 | 服务数量多、流程复杂、需要强管控 |
3.4 连接池水位与超时故障的关联
无论采用哪种模式，Saga 事务的长时间运行都会对数据库连接池产生直接影响。以下是两种模式下典型的连接池水位变化特征：
- 编排模式：每个服务在监听事件并执行本地事务时，会占用一个数据库连接。如果事件处理缓慢（如等待下游响应），连接占用时间变长，导致连接池水位上升。当大量补偿事件同时触发时，连接池可能瞬间被打满。
- 协调模式：协调器本身通常也需要数据库来持久化状态机。协调器在处理每个 Saga 实例时，会长时间持有数据库连接（用于更新状态）。当大量 Saga 实例处于等待响应的中间状态时，协调器的连接池水位会持续处于高位，极易触发连接池超时。
实战经验：在排查 Saga 超时故障时，不要只盯着业务代码。请同步检查协调器或事件消费者的数据库连接池活跃连接数。如果活跃连接数长期接近最大值，说明 Saga 事务的响应时间已经超过了连接池的承受能力，需要从超时配置、补偿策略或连接池扩容三个方向同时入手。