分布式调用第三方API需构建有判断、有退路、有边界的重试闭环：先按故障类型分“可重试/终止/查证”三分支；可重试分支启用指数退避+抖动循环（3～5次，延迟上限10s）；配合超时控制、并发限流与熔断机制；失败后依场景执行异步补偿、降级或token刷新。

在分布式环境下调用第三方 api，不能只靠“多试几次”——得让重试有判断、有退路、有边界。核心是把“是否重试”“怎么重试”“重试失败后怎么办”这三件事，用分支结构清晰拆解，并嵌入循环重试算法形成闭环。

识别故障类型，走不同分支路径

每次请求失败后，第一件事不是立刻重试，而是解析错误原因，进入对应分支：

• 网络层瞬时异常（如 ConnectTimeout、ReadTimeout、503/504/408）→ 进入「可重试分支」
• 业务逻辑错误（如 400/401/403/404、JSON 解析失败、签名无效）→ 进入「终止分支」，记录日志并返回明确错误
• 非幂等操作失败（如 POST 创建订单、支付回调）→ 进入「查证分支」：先调用查询接口确认状态，再决定跳过或告警，不盲目重试

在可重试分支中嵌入智能循环重试

进入可重试分支后，启用带指数退避 + 抖动的循环重试，避免雪崩：

• 设置最大尝试次数（建议 3～5 次），超过即退出循环
• 每次重试前计算延迟：delay = min(初始延迟 × multiplier^尝试次数, 最大间隔)，例如 1s → 2s → 4s → 8s（上限 10s）
• 在延迟基础上叠加 ±10% 随机抖动，打散重试时间点，防止下游被压垮
• 循环体内捕获异常，仅对预设重试码重试；其他异常（如 OOM、NPE）立即中断

超时与并发控制双保险

循环重试本身不解决资源耗尽问题，必须配合外部约束：

• 每个请求单独设置 HTTP 超时（connect + read），建议 ≤ 3s，防止单次卡死拖垮整个循环
• 使用信号量或线程池限制并发调用数（如最多 10 个并发请求），避免突发流量击穿限流阈值
• 对同一目标域名/IP 做熔断快照：5 分钟内失败率 > 50%，自动开启短时熔断（如 30 秒），跳过重试直接走降级

重试失败后必须有确定性兜底

循环结束仍失败，不能抛异常或静默丢弃，要按场景执行明确动作：

• 关键路径（如下单扣库存）→ 触发异步补偿任务（写 DB + 发 MQ），后续定时扫描重试
• 非关键路径（如发送通知、埋点上报）→ 降级为本地日志 + 异步批处理，或直接丢弃
• 凭证类失败（如 Access Token 失效）→ 调用刷新接口获取新 token，再重放原请求（需支持请求幂等封装）