重试是带成本核算的资源调度决策，需基于服务端负载、客户端资源水位和业务上下文权重三类实时变量加权判断是否重试，并动态调整参数，同时拦截4xx、已确认变更、非幂等等不可重试场景。

重试不是“再试一次”那么简单，而是一次带成本核算的资源调度决策。真正健壮的系统会在捕获异常后，先评估“值不值得重试”，而不是盲目执行预设次数。

重试代价的核心变量

是否重试，取决于三类实时资源变量的加权判断：

• 服务端负载信号：当前目标服务的错误率（>5%触发熔断）、P99延迟（>2s建议降级）、HTTP 503/504响应频次；这些指标比本地超时更真实反映问题可恢复性
• 客户端资源水位：当前线程池可用数、内存剩余率（85%暂缓新请求）；避免雪崩式自耗
• 业务上下文权重：该请求的SLA等级（如支付回调属P0）、数据幂等性（已落库则不可重试）、用户操作阶段（下单末步失败比首页加载失败代价高得多）

轻量级决策模型（无需ML）

用一个布尔表达式快速拍板，兼顾可读性与实效性：

is_retry_allowed = (target_service_health_score > 0.7) && (client_resource_utilization = 2)

其中：

• 服务健康分 = 1 − max(错误率/0.1, 延迟超标倍数/3, 503占比) —— 超出阈值即归零
• 客户端资源利用率 = max(内存使用率, 线程池饱和度, 连接池占用率)
• 业务紧急等级：1（后台批处理）、2（用户关键路径）、3（资金类强一致操作）

动态调整重试参数的实践要点

固定重试次数和退避间隔在真实场景中容易失效，应随代价评估结果联动调整：

• 当服务健康分低于0.5，直接跳过重试，走降级或告警流程
• 若客户端资源利用率 > 0.85，将指数退避的 base delay × 2，并减少最大重试次数1次
• 对业务等级为3的操作，允许单次重试但禁用自动退避，改为立即同步重发（需确保幂等）
• 每次重试前记录决策依据快照（如“因内存=87%跳过第2次重试”），用于事后归因

避免常见误判

有些异常类型根本不该进入重试决策流程，必须前置拦截：

• 4xx 错误（如 400 参数错误、401 认证失败）——属于客户端问题，重试无意义
• 已确认的数据变更（如库存已扣减成功但订单创建失败）——此时重试会破坏一致性，应启动补偿而非重试
• 非幂等操作（如重复调用“发起转账”）——未做幂等防护前禁止任何重试
• 超时发生在下游链路（如数据库慢查询），但本层响应正常——这不是重试问题，是监控盲区