掌握分布式系统中的指数退避（Exponential Backoff）

在分布式系统里，失败是常态而非例外——网络抖动、服务重启、限流都会让一次调用失败。重试是对付瞬时故障的基本手段，但无脑立即重试只会把正在恢复中的服务再次压垮。指数退避（Exponential Backoff）就是"聪明地重试"的标准答案：每次失败后等待的时间指数级拉长，给对端喘息空间。

三个核心概念

1. 重试机制：先想清楚哪些错误值得重试

不是所有失败都该重试：

• 值得重试：网络超时、连接重置、HTTP 429（限流）、502/503/504（服务端临时故障）。
• 不该重试：400/401/403/404（请求本身有问题，重试一万次也一样）、业务校验失败。

重试的基本骨架（JavaScript）：

async function retryOperation(operation, maxRetries) {
  let retries = 0;
  while (retries <= maxRetries) {
    try {
      return await operation();
    } catch (error) {
      if (retries >= maxRetries || !isRetryable(error)) throw error;
      retries++;
      // 这里还差一个等待策略 ↓
    }
  }
}

三个必备要素：可重试错误的识别、每次尝试的超时上限、最大重试次数（预算）。

2. 退避策略：等待时间是灵魂

公式：delay = base × 2^attempt，加一个上限封顶（如 32s）防止无限拉长。

3. 抖动（Jitter）：防惊群的关键

设想服务故障时有一万个客户端同时在重试——纯指数退避会让它们在同一时刻（1s 后、2s 后、4s 后）整齐地撞回来，形成"惊群效应"，服务刚缓过来又被拍死。

解法是给等待时间加随机抖动：

// Full Jitter（AWS 推荐）
const delay = random(0, Math.min(cap, base * 2 ** attempt));

抖动把重试时刻打散到随机时间点，恢复期的服务压力变得平滑。生产环境的指数退避必须带抖动。

完整实现

JavaScript 版：

async function retryWithBackoff(operation, {
  maxRetries = 5,
  baseDelay = 1000,
  maxDelay = 30000,
} = {}) {
  for (let attempt = 0; ; attempt++) {
    try {
      return await operation();
    } catch (error) {
      if (attempt >= maxRetries || !isRetryable(error)) throw error;

      const exp = Math.min(maxDelay, baseDelay * 2 ** attempt);
      const delay = Math.random() * exp;   // full jitter
      console.log(`第 ${attempt + 1} 次重试，等待 ${Math.round(delay)}ms`);
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

Go 版（用成熟的 backoff/v4 库）：

b := backoff.NewExponentialBackOff()
b.InitialInterval = 500 * time.Millisecond
b.Multiplier = 2.0
b.MaxInterval = 30 * time.Second
b.MaxElapsedTime = 3 * time.Minute

err := backoff.Retry(func() error {
    return callRemoteAPI()
}, backoff.WithContext(b, ctx))

什么时候用，什么时候别用

适合指数退避的场景：调用外部 API（支付、短信、云服务）、数据库连接恢复、消息队列重投递、微服务间调用。

不该用的场景：

• 用户正盯着屏幕等的请求：退避 30 秒对用户就是"网站卡死了"。用户路径上最多 1-2 次快速重试，然后快速失败、给出友好提示。
• 错误本身是永久的（4xx 类）：先判断错误性质。
• 自己就是瓶颈时：服务过载时更多重试=更多压力。这时候该用的是熔断。

更进一步：与熔断、限流组合拳

指数退避负责"单次调用失败怎么办"，更完整的韧性体系还包括：

• 熔断器（Circuit Breaker）：失败率超阈值后直接短路一段时间，请求快速失败，不再打到下游；
• 重试预算（Retry Budget）：全局限制重试流量占比（如不超过总流量的 10%），防止重试风暴；
• 幂等设计：重试的前提。非幂等操作（如扣款）重试可能产生重复——用幂等键解决。

观测云对照

重试行为本身值得监控：重试率突然升高，往往是下游服务劣化的最早信号——比错误率更早。通过观测云 APM 追踪服务间调用的重试次数与耗时，配合错误率监控告警，可以在用户感知到故障之前就发现"下游正在靠重试硬撑"的危险状态；链路视图里重试产生的重复 span 一目了然，帮你评估退避参数是否合理。

常见问题（FAQ）

Q：重试次数设多少合适？
A：一般 3-5 次。配合指数退避，5 次重试总等待约 31 秒（1+2+4+8+16），覆盖了绝大多数瞬时故障的恢复窗口。更多次数的边际收益急剧下降。

Q：幂等性怎么保证？
A：为每个操作生成唯一幂等键（如 UUID），服务端对相同键的请求去重；或利用业务天然幂等性（覆盖式写入）。消息队列消费用去重表。

Q：HTTP 客户端有现成的吗？
A：有。Python 的 tenacity、Java 的 Resilience4j、Go 的 backoff/v4、axios 生态的 axios-retry。理解原理后优先用成熟库，别手写。