WHAT — Vendor-neutral distribu…

# 电商支付接口容错方案设计

一、整体思路

• 分层防护：超时控制 → 重试 → 熔断 → 降级 → 兜底，层层递进。
• 目标：高峰期不让支付方故障拖垮下单主流程，最终保证订单最终一致。

二、重试模式设计

• 只重试幂等操作：调用支付前生成唯一支付请求号（幂等键），重试时复用，防止重复扣款。
• 重试策略：指数退避 + 随机抖动（如 100ms → 400ms → 1s），建议最多重试 2~3 次。
• 区分错误类型：
• 超时/网络抖动：可重试
• 参数错误/业务拒绝：不重试，直接走人工或失败流程
• 429/限流响应：不立即重试，延长退避
• 重试预算控制：限制单机重试流量占比（如不超过总调用的 10%），避免重试风暴放大故障。

三、断路器模式设计

• 以支付渠道为粒度设置断路器，三态流转：
• 闭合：正常调用，滑动窗口统计错误率（建议窗口 10 秒以上）
• 打开：错误率超阈值（建议 50% 左右起步，结合实测调整）或连续失败 N 次，直接拒绝调用，快速失败
• 半开：等待冷却期（建议 30~60 秒）后放少量探测请求，成功则恢复
• 实现选择：Java 用 Resilience4j，Go 用 sony/gobreaker，或直接用 Sentinel（自带熔断+限流）。

四、降级与兜底

• 熔断打开时切换降级策略：
• 优先切换到备用支付渠道（多渠道接入）
• 无备用渠道时：订单置为“待支付”状态，异步补偿任务轮询支付结果
• 前端提示用户稍后支付，而非下单失败
• 异步化削峰：下单后支付请求投递 MQ，消费者带重试和死信队列处理，平滑高峰压力。

五、监控与配套

• 监控指标：支付成功率、P99 耗时、熔断触发次数、重试比例，配置告警。
• 对账兜底：每日定时与支付方对账，补偿掉单。
• 压测验证：上线前模拟支付方超时/拒绝场景，验证熔断和降级生效。

六、落地优先级

1. 先加超时控制 + 幂等键（防资损）

2. 再上重试 + 断路器

3. 最后补齐多渠道降级与对账补偿