3. 超时场景分析：节点超时的常见原因
审批流节点超时并非单一故障所致，而是多种底层异常在业务层的共同表现。从分布式系统视角看，超时可归因于三大类：网络抖动、服务宕机与资源死锁。三类原因在发生频率、影响范围、恢复手段上差异显著，需分别建模与应对。
3.1 网络抖动
网络抖动是微服务架构中最常见的瞬时故障。表现为节点间通信延迟在短时间内剧烈波动，导致请求在客户端超时阈值内未收到响应。
| 特征维度 | 典型表现 | 影响范围 |
|---|---|---|
| 持续时间 | 毫秒级～秒级，通常 < 30s | 单次请求或局部链路 |
| 触发条件 | 网络队列拥塞、TCP 重传、DNS 解析延迟 | 跨机房/跨可用区调用 |
| 恢复方式 | 自动恢复，无需人工介入 | 重试 + 指数退避即可覆盖 |
| 对审批流影响 | 偶发超时，重试后通常成功 | 不触发补偿，仅记录告警 |
工程经验：网络抖动导致的超时，在日志中通常伴随
java.net.SocketTimeoutException: Read timed out 或 connect timed out。此类异常应优先采用幂等重试 + 指数退避策略，而非直接触发补偿流程。
3.2 服务宕机
服务宕机指审批流中某个节点所依赖的微服务实例因进程崩溃、OOM、硬件故障等原因完全不可用。与网络抖动不同，宕机通常持续数分钟至数小时，需要明确的故障转移或补偿动作。
- 进程级宕机：JVM 崩溃、容器 OOMKilled、应用线程池耗尽。
- 基础设施宕机：宿主机宕机、磁盘故障、网络设备中断。
- 依赖服务宕机：数据库连接池满、Redis 主从切换、消息队列积压。
关键区分：服务宕机与网络抖动的核心区别在于恢复时间。宕机场景下，重试策略在短时间内必然持续失败，必须由补偿机制接管，将审批流路由至备用节点或人工处理通道。
3.3 资源死锁
资源死锁是并发系统中特有的超时诱因。当多个审批节点或后台任务互相等待对方持有的资源（数据库行锁、分布式锁、线程池槽位）时，所有参与者均无法推进，最终触发超时。
| 死锁类型 | 典型场景 | 检测手段 |
|---|---|---|
| 数据库行锁死锁 | 两个审批节点同时更新同一条审批记录的不同字段 | MySQL SHOW ENGINE INNODB STATUS |
| 分布式锁死锁 | 节点 A 持有锁 1 等待锁 2，节点 B 持有锁 2 等待锁 1 | Redis 锁 TTL 超时 + 看门狗失效 |
| 线程池死锁 | 父任务提交子任务到同一线程池，子任务等待父任务释放槽位 | 线程 dump 分析 |
补偿策略差异：资源死锁导致的超时，单纯重试往往无效（死锁条件依然成立）。补偿机制应优先触发死锁检测 + 事务回滚，释放所有已持有资源，再重新调度审批节点。
3.4 三类超时原因对比
以下 SVG 图从发生频率、恢复难度、补偿必要性三个维度对比三类超时原因，帮助架构师快速判断不同场景下的处理优先级。
3.5 超时原因与补偿策略的映射关系
不同超时原因对应不同的补偿策略。下表总结了三种原因下的推荐处理路径，供架构设计时参考。
| 超时原因 | 检测方式 | 首选策略 | 补偿触发条件 |
|---|---|---|---|
| 网络抖动 | 超时异常 + 链路追踪 | 幂等重试（3次，指数退避） | 重试全部失败 |
| 服务宕机 | 健康检查失败 + 连续超时 | 故障转移 + 补偿任务 | 宕机超过 30s |
| 资源死锁 | 线程 dump / 锁超时日志 | 事务回滚 + 锁释放 | 死锁检测命中 |
架构建议：在审批流引擎中，建议为每个节点配置超时原因分类器。分类器根据异常类型、连续失败次数、依赖服务状态，自动判断当前超时属于哪一类，并路由到对应的补偿处理器。这比统一的重试或补偿策略更精准，能有效减少误补偿。