面经策

当客户端有重连机制，当服务意外宕机重新部署启动时，怎么避免流量洪峰？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

客户端有重连机制，服务端重启后全部连接同时重连重灌流量——这就是经典的"重连风暴/惊群"，能把刚重启的服务直接二次打死，形成"重启→被打挂→再重启"的循环。我从客户端、服务端、基础设施三层答，这也是真实 IM/推送系统的必修课。

客户端层（治本）

  • 指数退避 + 随机抖动（jitter）：重连间隔 1s → 2s → 4s... 上限 60s，每次加 0~50% 随机量——抖动是关键，它把"同一毫秒的十万重连"摊成一条平缓的曲线
  • 失败后重新拉取接入点列表，分散到不同节点
  • SDK 层统一实现，业务方无感知——治理必须在基建层收口，指望每个业务团队自己写对重连逻辑不现实

服务端层（自保）

  • 启动预热 + 流量缓升：注册中心权重从 0 慢慢调大（如每分钟 10%），或网关按健康检查逐级放量，避免新实例一上线就接满
  • 连接准入限流：每秒最大新建连接数（如 5000/s），超出的排队——已有连接的请求不受影响
  • 请求限流兜底：核心接口令牌桶，非核心直接降级

基础设施层

  • 网关/接入层 LB 摘流预热：先摘流量再重启（优雅下线），发布批次化（一次 10% 而不是全量）——全量重启是重连风暴的最大制造者，发布策略本身就是预防手段
  • 多可用区部署，单机房重启不影响全局

业务视角收尾：这类问题的投入产出极好——退避抖动 + 权重缓升两招就能消灭 90% 的风暴，成本是一个迭代；而一次风暴事故的代价是分钟级全服务不可用。我还会把"杀掉一台网关、观察重连曲线"纳入常态化混沌演练，验证这些机制真的生效。

🏗 系统架构师 ​

这是重连风暴问题：服务重启，成千上万客户端同时检测到断线并同时重连，刚重启的服务（连接池未热、JIT 未编译、缓存全空）直接被二次打死，形成"重启-被打挂-再重启"的恶性循环。

服务端改造：

  1. 优雅停机 + 快速失败：重启前先摘流量（注册中心反注册 + LB 摘除），排空在途请求再停进程，减少"感知到断线"的客户端数量
  2. 启动预热：K8s readinessProbe 就绪前不放流量；应用侧预热连接池、JIT、本地缓存；权重渐进提升（如 Nacos 权重从 10 逐步拉到 100）
  3. 限流与准入控制：网关/接入层对新连接设速率上限（如每秒最多接入 500 连接），超出的让客户端等下一轮；排队放行而不是全拒

客户端改造（治本）：

  1. 指数退避 + 抖动（最关键）：重连间隔 min(base * 2^n, max) + random抖动。例如 1s、2s、4s...上限 60s，每次加 0~1s 随机抖动——抖动把"同时重连"打散成均匀分布，这是 AWS 经典论文的核心结论
  2. 退避上限与压测校准：总重连速率必须低于服务端容量，客户端规模 10 万就要算出单客户端允许的频率
  3. 监听系统事件代替盲目轮询：监听网络恢复广播（Android 的 CONNECTIVITY_ACTION）再重连，避免无网空转

架构层根治：接入层多实例 + LB 健康检查，单实例重启只影响 1/N 连接；长连接系统用连接迁移（客户端重连时按 token 恢复会话状态）降低重连代价。

一句话：客户端退避加抖动打散、服务端预热限速放行、架构多实例分摊，三层配合风暴不会成形。

💻 全栈开发专家 ​

这是典型的重连风暴问题：服务重启，几万客户端同时检测到断线、同时重连、同时拉数据，服务刚启动就挨一记流量洪峰。我从客户端和服务端两侧治理。

客户端：随机退避（治本）

java
// 指数退避 + 全抖动（full jitter），打散重连时间
long base = 1000, cap = 60_000;
int attempt = ...;
long backoff = Math.min(cap, base * (1L << Math.min(attempt, 16)));
long delay = ThreadLocalRandom.current().nextLong(backoff); // 0 ~ backoff 随机
scheduleReconnect(delay);

没有 jitter 的退避是"整齐的浪潮"，一波一波打死服务；full jitter 把重连摊平成连续小雨。

服务端：预热 + 慢启动

  1. K8s 就绪探针：应用启动完成（连接管理器、缓存预热完毕）才标记 ready：
yaml
readinessProbe:
  httpGet: { path: /actuator/health/readiness, port: 8080 }
  initialDelaySeconds: 30
  1. 流量慢启动：网关/注册中心给新实例低权重，逐步放量到正常权重（Nacos 权重调 1 → 10，或网关按实例权重路由），给 JIT 预热和缓存填充留时间。
  2. 启动即限流：Sentinel 冷启动 WarmUp 模式，QPS 阈值从低爬坡到正常，超出的排队/拒绝。
  3. 本地缓存兜底：重连后客户端先拉增量数据（本地有版本号/序列号，只同步 delta），别一上线全量 pull——把服务端压力从 O(全量) 降到 O(增量)。

复盘经验：长连接网关类服务，发布时"先摘流再重启、ready 后慢放量"要做成标准流程，比出事后再救火便宜得多。