发布时的建连风暴
应用发布时批量建连会形成瞬时压力：每个副本启动都要建立池内连接、完成认证与初始化，多个副本同时发布时这些动作叠加，新建连接速率短时间飙高，服务端要处理大量握手与内存分配。做法是连接池分阶段填充、预热完成后再接入流量，并把预热与就绪检查串起来，让流量只打到已就绪的实例。
基本信息
| 问题表现 | 启动瞬间建连风暴，新建连接速率短时飙高 |
|---|---|
| 缓解方案 | 连接池渐进填充，预热完成后放量 |
| 验证指标 | rejected_connections 与连接数曲线 |
| 发布配合 | 滚动发布，预热与就绪检查串联 |
| 池参数 | 初始化连接数、最大连接数、获取连接超时 |
典型使用场景
- 滚动发布：逐批上线，避免所有副本同时建连
- 弹性扩容：新副本启动时集中建连，需要对填充速率限速
- 大促扩容：提前扩容并把连接预热做在流量上涨之前
- 故障恢复：实例恢复后客户端同时重连，预热策略用来削峰
- 发布验收：看连接数与拒绝量，确认没有出现异常尖峰
两端一起看
两端一起看
redis-cli INFO clients | grep -E 'connected_clients|maxclients' # 连接水位与上限
redis-cli INFO stats | grep rejected_connections # 是否出现拒绝
redis-cli INFO clients | grep client_recent_max_input_buffer # 单连接缓冲峰值
redis-cli INFO stats | grep total_connections_received # 新建连接速率
# 应用侧示意：池按批填充，例如每批 5 条连接、间隔 200ms，填满后再接流量发布阶段对照
| 阶段 | 连接行为 | 要看什么 |
|---|---|---|
| 副本启动 | 池开始建立连接 | 建连速率是否被限住 |
| 预热完成 | 池达到目标连接数 | 延迟与错误率是否正常 |
| 接入流量 | 流量逐步导入 | 拒绝量是否保持为零 |
| 全量运行 | 连接数趋于稳定 | 连接数不再持续上涨 |
预热与就绪检查要串起来：就绪通过才把实例放进负载列表，否则流量会在池还没填满时打进来，由冷连接承担高峰。
多个副本同时发布会让建连风暴叠加，服务端短时间内要处理成倍的新建连接；分批发布加限速填充是成本最低的做法。