服务宕机重启时，如何避免客户端重连流量洪峰？

日期：2026-07-12
标签：#面试 #八股 #后端 #重连 #高可用 #场景题

一句话答案

客户端使用指数退避和随机抖动，服务端分批摘挂流量、限速握手和延迟就绪，并通过会话恢复与多节点分散重连，避免所有客户端同时冲击单实例。

面试口语版

重连风暴的根因是大量客户端使用固定间隔同时重试。客户端应采用指数退避加 full jitter，并设置最大间隔、总重试时间和服务端下发的 Retry-After。服务重启后先完成缓存预热、连接池和依赖检查，再进入 Readiness；网关按比例灰度放量，并限制每秒新连接和鉴权并发，超出部分排队或快速返回重试时间。长连接会话用 token 和最后序号恢复，不做全量状态拉取。集群通过负载均衡、连接迁移和容量预留分摊洪峰。

流程图

flowchart LR
  A[连接断开] --> B[指数退避加随机抖动]
  B --> C[负载均衡分散实例]
  C --> D[服务端新连接限速]
  D --> E[轻量鉴权与会话恢复]
  E --> F[逐步恢复正常流量]

关键细节

固定 1 秒重试会形成同步脉冲，抖动必须随机化。
Kubernetes Pod Ready 不等于业务已预热完成。
TLS、鉴权、会话加载往往比空连接更消耗资源。
监控新建连接速率、握手 P99、拒绝数和恢复时间。

面试官追问

指数退避为什么还要加随机抖动？
服务端如何告诉客户端晚点重试？
重连后如何避免全量同步消息？

面试官追问参考答案

1. 指数退避为什么还要加随机抖动？

如果所有客户端从同一时间断开，即使采用相同指数序列也会在 1、2、4 秒同时重试。随机抖动把请求摊到时间窗口内，降低瞬时峰值和再次失败的同步振荡。

2. 服务端如何告诉客户端晚点重试？

HTTP 握手可返回 429/503 和 Retry-After，自定义协议可返回退避毫秒、错误类型和服务版本。客户端应尊重上限并加入本地抖动，不能无条件立即重试。

3. 重连后如何避免全量同步消息？

客户端携带上次确认的会话 seq 或全局同步游标，服务端只返回缺失增量；服务端保留可恢复窗口，超出窗口才做分页全量同步。消息按 ID 去重并限制单次补拉大小。

学习清单

掌握退避、抖动、灰度放量和会话恢复。
能识别握手与鉴权的隐性成本。