2. 超时配置基础：超时概念、超时类型与事务一致性影响

在分布式 Saga 事务中，超时是保障系统可靠性的第一道防线。超时配置不仅决定了请求的响应边界，更直接影响了事务的最终一致性、资源释放效率和补偿执行的正确性。本节从超时的核心概念出发，系统梳理三种超时类型及其对事务一致性的影响。

2.1 超时核心概念

超时（Timeout）是指系统在等待某个操作完成时，允许的最大等待时间。一旦超过该时间阈值，系统将主动中断等待并执行预设的降级或补偿逻辑。在 Saga 事务中，超时机制用于防止以下三类问题：

• 资源死锁：参与者长时间持有数据库锁或连接池资源，导致系统吞吐量骤降。
• 级联等待：一个子事务的延迟引发后续所有子事务的连锁等待，最终导致事务整体超时。
• 状态不确定：参与者因网络分区或进程崩溃未返回结果，协调器无法判断事务应提交还是回滚。

2.2 超时类型详解

根据超时作用域的不同，Saga 事务中的超时可分为以下三种类型：

2.2.1 请求超时（Request Timeout）

请求超时是最底层的超时粒度，作用于 Saga 协调器与参与者之间的每一次远程调用。当参与者服务响应缓慢或网络出现抖动时，请求超时能够快速释放调用线程，避免线程池耗尽。请求超时通常与重试机制配合使用：

// 请求超时配置示例（Spring Cloud + Resilience4j）
@Bean
public TimeLimiterConfig timeLimiterConfig() {
    return TimeLimiterConfig.custom()
        .timeoutDuration(Duration.ofMillis(1500))  // 请求超时 1.5s
        .cancelRunningFuture(true)                  // 超时后取消正在执行的任务
        .build();
}

2.2.2 事务超时（Transaction Timeout）

事务超时是 Saga 协调器层面的全局超时，从事务发起开始计时，到所有子事务执行完毕或补偿完成结束。事务超时用于防止“慢事务”长时间占用协调器内存和状态存储资源。当事务超时触发时，协调器会立即中断当前正在执行的子事务，并启动对所有已成功子事务的补偿流程。

2.2.3 补偿超时（Compensation Timeout）

补偿超时专门用于 Saga 的回滚阶段。当某个子事务失败或事务整体超时后，协调器会依次调用已成功子事务的补偿接口。补偿操作本身也可能失败或超时，因此需要独立的超时配置。补偿超时通常比请求超时更宽松，因为补偿操作可能涉及数据清理、资源释放等耗时操作。

2.3 超时对事务一致性的影响

超时配置不当会从以下三个维度破坏 Saga 事务的一致性：

1. 数据不一致窗口扩大：请求超时设置过长，导致参与者长时间处于“已提交但未确认”状态，增加全局不一致的时间窗口。
2. 补偿遗漏：补偿超时设置过短，补偿操作被强制中断，导致已提交的子事务无法被撤销，产生“脏数据”。
3. 幽灵事务：事务超时触发后，协调器开始补偿，但某个子事务的请求超时恰好同时触发重试，导致该子事务在补偿完成后又被重新提交，造成最终状态混乱。

2.4 超时配置与一致性的关系图

下图展示了三种超时类型在 Saga 事务生命周期中的位置及其对一致性的影响路径：

2.5 超时配置的常见陷阱

• 陷阱一：全局统一超时——所有子事务使用相同的超时值，忽略了不同服务的响应特性差异（如支付服务通常比查询服务慢）。
• 陷阱二：超时与重试耦合——请求超时后立即重试，但未考虑重试次数上限，导致“超时风暴”压垮下游服务。
• 陷阱三：忽略网络延迟——在跨机房或跨地域部署场景下，未将网络 RTT 纳入超时计算，导致正常请求频繁超时。
• 陷阱四：补偿超时等于请求超时——补偿操作可能涉及数据回滚和资源释放，通常比正向操作更慢，需要独立且更宽松的超时配置。