一次 401 风暴让 3800 个会话同时掉线：并发 token 刷新的根因与单飞治理

作者：顾砚舟-304｜前端｜稳定性与可观测性 栈：React 18.2.39 + Vite 5.4 + axios 1.7.2 + TypeScript 5.5

一、现象与背景：一次发版后的「批量掉线」

先摆数字。我们一个 B 端数据中台（约 40 个页面、核心列表页默认 3s 轮询 + 顶部筛选栏可触发 4~6 个并发接口），2024 年底一次网关侧 token 过期时长从 2h 调到 45min 后，上线第 2 天下午，客服 30 分钟内收到 217 条「一刷新就要求重新登录」的工单。

监控侧我看到三组异常曲线：

• POST /auth/refresh 在 90 秒内被调用 4138 次（基线日均才约 900 次/天），峰值 47 QPS；
• 同一时间窗内，401 响应占比从 0.3% 飙到 6.8%；
• 掉线的不是零散用户，而是同一批 3800 个活跃会话在 2 分钟内集中失效——这本身就违反直觉，正常 token 过期应该是平滑的。

影响：那一小时核心看板不可用，业务方投诉 3 起，值班同学一度以为是网关挂了。

二、原理与根因：为什么「过期」会放大成「风暴」

根因一句话：我们把「token 过期」这个单点事件，写进了 N 个并发请求各自的失败回调里，于是 1 次过期被放大成 N 次刷新、N 次二次 401、N 次强制登出。

机制拆开看（这是关键，很多人只看到 401 就跳登出）：

1. 某时刻 access_token 到期。此刻用户页面上有 5 个 in-flight 请求（轮询 1 个 + 筛选联动 4 个），它们几乎同时打到网关，同时收到 401。
2. 我们旧代码在每个请求的 axios response interceptor 里对 401 的处理是：await refreshToken() → 拿到新 token → 重放当前请求。
3. 问题在于 refreshToken() 是 5 个请求各自独立发起的。于是 1 次过期变成 5 次 refresh。
4. 更致命的是 refresh 本身也有耗时（约 180~260ms）。在这 200ms 窗口里，后续新发起的请求仍带着已被服务端吊销的旧 token（我们的 refresh 是「换发即吊销旧 token」策略），于是这批请求再次 401，又各自触发 refresh……
5. 结果形成正反馈：refresh 被打到 47 QPS，触发了网关对 /auth/refresh 的限流（阈值 30 QPS），限流返回 429，而我们的兜底逻辑对「刷新失败」一律 logout() —— 于是一批本来只是 token 到期的用户，被直接登出了。

一句话：过期是概率事件，但「并发 + 各自刷新 + 刷新即吊销 + 刷新失败即登出」把概率事件变成了确定性事故。

三、具体做法：单飞（single-flight）+ 请求队列 + 失败降级

核心思想：同一时刻只允许一个 refresh 在飞，其余并发请求挂起排队，等这唯一一次刷新成功后统一重放。 用 axios 拦截器实现，关键片段：

// token 单飞：用一个共享 Promise 收敛所有并发刷新
let refreshing: Promise<string> | null = null;

function refreshOnce(): Promise<string> {
  if (!refreshing) {
    refreshing = api
      .post<{ accessToken: string }>('/auth/refresh', {}, {
        // 关键：刷新请求本身不能走 401 拦截器，否则会自我递归
        headers: { 'X-No-Retry': '1' },
        timeout: 3000,
      })
      .then((r) => {
        const t = r.data.accessToken;
        store.setToken(t);
        return t;
      })
      .finally(() => {
        // 无论成败都要清空，否则失败后永远卡在「刷新中」
        refreshing = null;
      });
  }
  return refreshing; // 并发调用者拿到同一个 Promise
}

// 401 拦截器：刷新 → 重放；刷新失败 → 降级而不是无脑登出
axios.interceptors.response.use(
  (res) => res,
  async (err) => {
    const { config, response } = err;
    if (response?.status === 401 && !config.headers['X-No-Retry']) {
      try {
        const newToken = await refreshOnce();
        config.headers['Authorization'] = `Bearer ${newToken}`;
        return axios(config); // 重放
      } catch (e) {
        // 区分「真过期登出」和「刷新接口本身挂了」
        if (isAuthGone(e)) {
          logout(); // 仅当明确 401（token 彻底失效）才登出
        }
        throw e; // 429/5xx：保留登录态，把错误抛给上层做重试/提示
      }
    }
    throw err;
  }
);

三个配套细节（缺一个都会打回原形）：

1. 刷新即吊销的旧 token 要留一个宽限窗。我和后端约定：旧 token 在 refresh 成功后仍保留 30s 有效（滑动吊销），给「刷新窗口里仍在飞的老请求」留缓冲，避免二次 401。
2. /auth/refresh 的限流阈值从 30 QPS 提到 120 QPS，并改成按「会话」而不是「IP」限流——因为一个会话内并发请求本就该共用一次刷新，按 IP 限流会把正常并发误伤。
3. 可观测性埋点（这是我作为稳定性岗最看重的一块）：
   • 上报 token_refresh_started / token_refresh_succeeded / token_refresh_failed；
   • 上报 concurrent_401_burst：当 1s 内同一会话出现 ≥3 个 401 就打点——这个指标是我们后来发现「刷新风暴」复发的唯一早期信号，比 401 占比灵敏得多。

四、踩过的坑 / 反直觉之处

1. .finally() 里清空 refreshing 是必须的，最容易漏。 漏掉它，一旦某次刷新抛错，refreshing 永远指向那个 rejected 的 Promise，之后所有请求都会拿到同一个死 Promise，整个前端「卡死在刷新中」，现象极其诡异——我调试时一度以为是内存泄漏。
2. 刷新请求自己不能进 401 拦截器。 否则 refresh 返回 401 → 触发 refresh → 无限递归，栈直接爆。靠 X-No-Retry 头（或 config._isRefresh 标记）排除。
3. 别把「刷新失败」和「token 真失效」混为一谈。 旧代码对一切刷新失败都 logout()，这等于把「网关抖动 500」也当成「你被踢下线」。必须区分：只有明确的 401（token 彻底无效）才登出，429/5xx 应保留登录态交给上层重试。
4. 限流维度选错会反噬。 按 IP 限流 refresh，在 NAT/公司网出口下，多个会话共用一个出口 IP，正常并发也会被限——改成按会话限流后误伤归零。
5. 反直觉：并发越多，「各自重试」越危险。 直觉上并发高就该多备几条路，但 token 刷新是共享资源，并发越高越要收敛成单飞，而不是放开。

五、结论与可复用清单

结论：token 过期是概率事件，能不能演变成事故，取决于你把它写进了多少个并发请求的失败路径里。 治理原则就三条——刷新单飞、失败分级、早信号埋点。

可复用清单（可直接抄）：

• [ ] access_token 并发刷新必须 single-flight：共享一个 refreshing Promise，finally 里清空；
• [ ] 刷新请求用 X-No-Retry（或 _isRefresh 标记）排除出 401 拦截器，防递归；
• [ ] 刷新失败要分级：仅明确 401 才 logout()，429/5xx 保留登录态交上层重试；
• [ ] 和后端约定「换发即吊销」留 ≥30s 滑动宽限窗，吸收刷新窗口内的老请求；
• [ ] refresh 限流按会话而非 IP，阈值要覆盖单会话真实并发（我们的并发峰值约 6，阈值 120 QPS 留足余量）；
• [ ] 埋点 token_refresh_* 三件套 + concurrent_401_burst（1s 内 ≥3 个 401 即打点）——这是风暴复发的唯一早期信号。

上线后 2 周数据：/auth/refresh 峰值从 47 QPS 回落到 6 QPS，401 占比稳定在 0.3%，「批量掉线」工单归零。