4. Saga超时机制：超时时间配置、超时触发条件、超时后的默认行为

Saga事务的超时机制是保障分布式系统数据最终一致性的最后一道防线。当某个本地事务因慢查询、连接池枯竭或网络抖动而迟迟无法完成时，超时机制必须能够准确识别、快速触发并执行补偿。本章从配置、触发条件与默认行为三个维度展开，帮助你在生产环境中精准设定超时策略。

4.1 超时时间配置：粒度与位置

超时配置并非单一参数，而是贯穿Saga协调器、事务参与者与消息中间件的多层设定。下表列出核心配置项及其推荐范围：

4.2 超时触发条件：三种典型场景

超时并非只在“执行时间过长”时触发。实际生产环境中，以下三种条件均会导致Saga超时：

1. 执行超时（Execution Timeout）：本地事务SQL执行时间超过步骤级配置的timeout值。常见于慢查询、锁等待或死锁。
2. 响应超时（Response Timeout）：协调器发送请求后，在消息队列超时时间内未收到参与者的ACK或结果。常见于连接池耗尽导致请求被阻塞在队列中。
3. 全局超时（Global Timeout）：整个Saga生命周期超过global-timeout-ms。即使每个步骤都未超时，但步骤间协调延迟累积也可能触发全局超时。

4.3 超时触发后的默认行为

当超时被触发，Saga协调器会按照预定义的策略执行补偿。默认行为分为三个阶段：

• 阶段一：标记失败 —— 将当前步骤状态标记为TIMEOUT，并记录超时原因（执行超时/响应超时/全局超时）。
• 阶段二：触发补偿 —— 立即中断当前Saga实例，不再执行后续正向步骤。协调器从已成功提交的步骤中，按逆序调用对应的补偿事务。
• 阶段三：重试或挂起 —— 如果补偿操作本身也超时，默认行为是重试3次（间隔指数退避：1s、2s、4s）。若重试全部失败，Saga进入SUSPENDED状态，等待人工介入。

以下SVG图展示了超时触发后的完整补偿流程：

4.4 超时行为对比：不同框架的默认策略

主流Saga框架在超时后的默认行为上存在差异，理解这些差异有助于你在选型时做出正确判断：

4.5 超时与连接池水位的联动关系

超时机制与连接池水位之间存在强耦合。当连接池水位接近上限时，请求等待连接的时间会急剧增加，导致响应超时频繁触发。以下SVG图展示了这种联动关系：

从图中可以看出，当连接池使用率超过70%时，Saga超时触发概率呈指数级上升。这是因为请求在连接池队列中的等待时间超过了步骤级超时配置。因此，监控连接池水位是预防Saga超时的第一道防线。