前端超时与重试治理：无限等待 + 自动重发曾把网关 502 打到 3.2%

作者顾亦舟

前端稳定性超时治理重试策略可观测性

结论先行

2024 年 Q3 我们一个 B 端数据平台的网关 502 比例从基线 0.4% 飙到 3.2%，值班同学以为是网关挂了。排查后发现根因在前端：请求层没有超时上限、失败后无条件自动重发，在弱网场景下形成了「请求堆积 → 网关过载 → 更多超时 → 更多重试」的正反馈。治理后 502 比例 7 天内回落到 0.31%，客户端侧「卡 30 秒以上」的会话占比从 6.8% 降到 0.4%。这篇文章把现象、机制、可复现的代码和踩过的坑完整讲清楚。

一、现象与背景

规模先交代清楚：该平台日均前端请求约 230 万，P95 服务端耗时 800ms，但 P99 是 4.7 秒。网关超时配置是 5 秒，客户端侧的 fetch 封装没有设任何超时，且有一行「失败就重试 2 次」的兜底逻辑。

出事的触发点是移动端弱网：一批用户从公司 WiFi 切到 4G，同一接口的客户端耗时拉到 12–30 秒。这些请求在网关侧早已 5 秒超时断开，但前端的 TCP 连接和 fetch 还挂着，用户手动刷新后又叠加新一波请求，失败的重试再叠加。监控上看到一个很反常的信号：网关连接数涨到平时的 4.3 倍，但 QPS 只涨了 1.8 倍——连接在涨、吞吐没涨，说明大量连接是被前端「占着不放」的死连接。

二、根因分析：为什么「没超时」比「超时」更危险

机制上三个因素叠加：

无超时 = 请求生命周期无上界。fetch 底层依赖 TCP keep-alive，弱网下包丢失后重传，一个请求挂 30 秒完全可能。这 30 秒里，前端的 loading 态、并发槽位（我们封装了并发上限 10 个）都被占住，后续所有请求都在排队等一个永远不会回来的响应。
重试放大了不对称。网关 5 秒就放弃了，客户端 30 秒才放弃——重试发生的那一刻，服务端状态可能已经变了（事务已回滚、幂等键已消费）。对 GET 重试是安全的，但我们的「失败重试 2 次」对 POST 也生效，这是最大的放大器。
正反馈回路。N 个前端 × 每页 5 个并发槽位 × 每次失败再发 3 次，弱网高峰时单用户就能打出 15 个在飞请求，230 万日请求的场景下，网关连接池（8000）被吃满只是时间问题。

一句话：超时的本质是「客户端对服务端承诺的回应」，没有超时就是单方面挂起，重试则是把挂起变成加倍挂起。

三、具体做法（可复现）

1) 给每个请求加硬超时，且超时值 = 网关超时 × 1.2

// 网关超时 5s，客户端取 6s：让网关先断，客户端永远不「多等」
function fetchWithTimeout(url: string, init: RequestInit = {}, timeoutMs = 6000) {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(new DOMException('timeout', 'TimeoutError')), timeoutMs);
  return fetch(url, { ...init, signal: ctrl.signal })
    .finally(() => clearTimeout(timer));
}

要点：6s 不是拍脑袋，它必须略大于网关的 5s，保证「服务端先超时、客户端收到明确错误」，而不是客户端先超时、服务端还在算。这个顺序错了，重试就可能打到「还在跑」的请求上。

2) 重试规则：只重试 GET，POST 必须带幂等键

const RETRYABLE = new Set(['TimeoutError', 'network']);
async function request(url: string, init: RequestInit, idempotencyKey?: string) {
  let lastErr;
  for (let i = 0; i < 3; i++) {
    try {
      return await fetchWithTimeout(url, {
        ...init,
        headers: init.method === 'POST' && idempotencyKey
          ? { ...init.headers, 'Idempotency-Key': idempotencyKey }
          : init.headers,
      });
    } catch (e) {
      lastErr = e;
      if (init.method !== 'GET' || !RETRYABLE.has(e.name)) throw e; // POST 无幂等键直接抛
      await sleep(Math.min(1000 * 2 ** i, 8000) * (0.5 + Math.random() / 2)); // 指数退避 + 抖动
    }
  }
  throw lastErr;
}

关键数字：退避基数 1s、上限 8s、抖动系数 0.5–1.0（避免重试风暴对齐）。抖动是必须的——1000 个客户端同时失败、同时等 1s、同时重试，就是第二次正反馈。

3) 前端侧熔断：60 秒滑动窗口

// 单接口维度：60s 窗口内失败率 > 50% 且样本 ≥ 10，熔断 30s
const window = 60_000, minSamples = 10, threshold = 0.5;
class Breaker {
  hits: number[] = []; fails: number[] = []; openedAt = 0;
  allow() { return Date.now() - this.openedAt > 30_000; }
  record(ok: boolean) {
    const now = Date.now();
    this.hits = this.hits.filter(t => now - t < window);
    this.fails = this.fails.filter(t => now - t < window);
    this.hits.push(now); if (!ok) this.fails.push(now);
    if (this.hits.length >= minSamples && this.fails.length / this.hits.length > threshold) {
      this.openedAt = now;
    }
  }
}

熔断打开时 UI 直接给「服务繁忙，稍后再试」，不再发请求。这一步把弱网高峰的在飞请求数从 15 压回 3 以内。

四、踩过的坑（反直觉的部分）

AbortController 不会立刻释放连接。我们以为 abort 后连接马上归还给池，实测 TCP 层 FIN 还要走一轮 RTT，弱网下要 200–400ms。所以并发槽位的释放必须在 JS 层手动计数，不能依赖连接状态，否则槽位会虚占。
POST 带 Idempotency-Key 后，「重试成功」的语义变了。服务端第一次请求可能已经执行成功、只是响应丢了，带同一 key 重试会返回第一次的结果而不是新执行。前端必须把这种情况当成功处理，我们最初当失败处理，导致用户看到「提交失败」但数据其实已入库，客诉 11 起。
超时值设成网关的 5s 整，会出现「同时超时」的竞态。客户端和服务端同一毫秒超时，客户端抛 TimeoutError 触发重试，服务端此时刚好写完响应——重试打到已完成的请求上，POST 场景直接重复执行。改成 6s 后这个窗口就消失了。
熔断的 minSamples=10 是踩出来的。最初没设最小样本，一个用户刷 3 次失败就触发了全端熔断，影响面 2000+ 用户。加上样本门槛后误触发归零。

五、结论与可复用清单

超时治理不是「加个 setTimeout」，而是一套客户端与服务端的时间契约：

[ ] 客户端超时 = 网关超时 × 1.2（保证服务端先断）
[ ] 只重试 GET；POST 重试必须携带 Idempotency-Key
[ ] 退避带抖动（0.5–1.0 随机系数），上限 8s
[ ] 单接口 60s 滑动窗口熔断：失败率 >50% 且样本 ≥10，熔断 30s
[ ] 并发槽位在 JS 层手动计数，不依赖连接状态
[ ] RUM 上报三个指标：fetch_timeout_total、fetch_retry_total、breaker_open_total，弱网告警看这三个而不是只看 5xx

一句话：没有超时的前端，是在用自己的连接数赌网络；超时 + 幂等 + 熔断三件套，把「赌」变成了「预算」。

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。