通过Nginx stub_status模块采集Active connections等指标，结合QPS、业务节奏与历史比例建模，可预测大促并发峰值；需关注Waiting占比、Reading/Writing趋势，并联动监控阈值与弹性扩缩容。
通过 Nginx 的 stub_status 模块实时采集连接状态指标，结合历史趋势与业务节奏建模，可较准确地预判大促期间并发连接数的峰值。
理解 stub_status 的关键指标含义
stub_status 返回三行数据，例如：
Active connections: 1247
server accepts handled requests
245873 245873 654982
Reading: 3 Writing: 12 Waiting: 1232
其中真正反映瞬时压力的是：
- Active connections：当前所有活跃连接数（含 keepalive 空闲连接）
- Waiting：处于 keepalive 状态、等待新请求的空闲连接数
- Reading + Writing：正在处理请求的连接数（即真实工作连接）
大促压测和监控中，应重点关注 Active connections 的分钟级波动极值，并区分 Waiting 占比——若 Waiting 长期超 90%，说明连接复用率高、实际负载未必饱和；若 Reading/Writing 持续攀升且 Waiting 快速下降，则是真实并发上涨信号。
构建连接数峰值预测模型
单纯看实时值无法预测峰值，需建立轻量级时序映射关系：
-
以流量入口为锚点：将 CDN 回源 QPS、上游网关请求量、或支付/下单接口调用量作为输入特征，与对应时刻的
Active connections做滑动窗口相关性分析（如 1–3 分钟延迟窗口），拟合出连接数 ≈ k × QPS + b 的经验系数 - 叠加业务节奏因子：大促通常有明确节奏（如零点开抢、整点红包、前 10 分钟爆发），在模型中引入时间偏移权重（例如 t=0 时权重 1.8，t=5min 时降为 1.2），提升首波高峰预测精度
- 参考历史同量级活动：不追求绝对数值复刻，而是提取“QPS 上涨 3 倍 → 连接数上涨 2.3~2.6 倍”的比例区间，用于交叉验证实时预测结果
落地建议：监控 + 阈值 + 自动响应
预测不是目的，支撑容量决策才是关键：
- 将
Active connections的预测峰值与当前 Nginx worker 进程数、worker_connections设置做比对，当预测值达配置上限的 75% 时触发预警 - 在大促前 30 分钟启动高频采集（如 5 秒一采），用移动平均滤除毛刺，同时计算近 1 分钟最大斜率（Δconnections/Δt），斜率突增 300% 可视为“峰值临近”信号
- 与弹性扩缩容系统联动：当预测峰值超过当前集群承载能力，自动触发备用节点上线或临时调高
worker_connections（需提前验证句柄限制）
注意 stub_status 的常见偏差场景
避免被表象误导：
- 客户端大量短连接未设 keepalive，导致
Active connections数值虚低，但实际新建连接频次极高——此时应同步监控accepts累计量的秒级增量 - 后端响应慢造成连接积压，
Writing长时间不降，Active connections持续走高，但这反映的是下游瓶颈，而非入口真实并发需求 - 多个 Nginx 实例共用同一 upstream，单机连接数平稳，但 upstream 已打满——必须结合后端连接池指标（如 Tomcat activeThreads）联合判断
