CLOUD云枢在阿里云负载均衡（SLB/ALB/NLB）中，“并发连接数”和“每秒请求数”是两个核心但极易混淆的性能指标。要理解它们的区别，不能只看定义，必须结合 HTTP/TCP 协议特性以及云产品的计费与限流逻辑来看。
1. 核心定义区别
并发连接数 (Concurrent Connections)
- 本质：指在同一时刻，负载均衡器与后端服务器之间（或客户端与 LB 之间）保持活跃的 TCP 连接数量。
- 状态：包括
ESTABLISHED（已建立）、TIME_WAIT（等待关闭）等状态的连接。只要三次握手完成且未完全四次挥手断开，都算作一个并发连接。 - 单位：个（Count）。
- 关键场景：WebSocket、长轮询、Keep-Alive 长连接场景下，这个数值会显著高于 QPS。
每秒请求数 (QPS – Queries Per Second / RPS)
- 本质：指负载均衡器在单位时间（1秒）内成功处理的 HTTP/HTTPS 请求总数。
- 计算方式：通常基于应用层（Layer 7）的 HTTP 请求头解析。对于 NLB（四层），有时也指新建的 TCP 连接数或数据包处理速率，但在 SLB/ALB 语境下，默认指 HTTP 请求。
- 单位：次/秒（req/s）。
- 关键场景：传统 RESTful API、静态资源访问、短连接 Web 服务。
2. 为什么两者数值差异巨大？——Keep-Alive 的影响
这是最核心的区别来源。HTTP Keep-Alive（持久连接） 的存在，使得“一个连接”可以承载“多个请求”。
场景 A：开启 Keep-Alive（常见于现代 Web 服务）
- 行为：客户端与 LB 建立一次 TCP 连接后，可以在该连接上发送多个 HTTP 请求（如加载 HTML、CSS、JS、图片等）。
- 结果：
- 并发连接数：较低。例如，10,000 个用户同时访问页面，可能只维持 5,000 个活跃 TCP 连接（因为部分连接复用）。
- QPS：较高。这 5,000 个连接可能在 1 秒内发起 50,000 个 HTTP 请求。
- 关系：QPS >> 并发连接数。
场景 B：关闭 Keep-Alive 或使用 HTTP/1.0
- 行为：每个 HTTP 请求都需要建立一个新的 TCP 连接，请求结束后立即断开。
- 结果：
- 并发连接数：与 QPS 接近（考虑 TIME_WAIT 延迟，并发连接数可能略高于瞬时 QPS）。
- QPS：等于每秒新建的连接数。
- 关系：QPS ≈ 并发连接数（忽略网络延迟带来的微小偏差）。
场景 C：WebSocket 或长连接业务
- 行为：连接一旦建立，长期保持，不频繁发送请求。
- 结果：
- 并发连接数：极高（直接反映在线用户数）。
- QPS：极低（可能只有心跳包）。
- 关系：并发连接数 >> QPS。
3. 阿里云产品层面的具体体现
不同实例类型的 SLB 对这两个指标的监控和限制方式不同：
| 特性 | 传统型负载均衡 (CLB) | 应用型负载均衡 (ALB) | 网络型负载均衡 (NLB) |
|---|---|---|---|
| 主要协议 | 七层 (HTTP/HTTPS) + 四层 (TCP/UDP) | 七层 (HTTP/HTTPS) | 四层 (TCP/UDP) |
| 并发连接数 | 重要限制项。旧版按规格收费时，最大并发连接数是硬性上限。新版按量付费也需关注此值以防触发限流。 | 同样有上限，但 ALB 更侧重规则匹配能力。 | 核心性能指标。NLB 的高性能体现在极高的并发连接处理能力（百万级）。 |
| QPS/RPS | CLB 实例规格决定最大 QPS。超出后会丢弃请求或返回 502/504。 | ALB 的 QPS 能力通常更高，且支持自动伸缩。 | NLB 不直接提供 HTTP QPS 概念，而是看 TPS（每秒事务数）或带宽。 |
| 监控重点 | 监控面板中两者均有展示。重点关注“连接数超限”告警。 | 更精细化的 URL/Host 级别 QPS 统计。 | 关注连接队列长度、新建连接速率。 |
注意：阿里云近年来推行“按量付费”和“性能保障型”实例，部分老规格的“最大并发连接数”硬限制已逐渐被“性能等级”所取代，但并发连接数仍是衡量后端服务器压力的关键指标。如果并发连接数打满，即使 QPS 很低，新的连接也会被拒绝。
4. 实际运维中的判断逻辑
当你遇到性能瓶颈时，如何区分是“连接数问题”还是“QPS 问题”？
-
查看监控图表：
- 如果 并发连接数 接近实例上限，而 QPS 远低于上限 → 问题在于长连接堆积或连接泄漏。检查后端服务是否正确关闭连接，是否使用了 WebSocket 但未做连接池管理。
- 如果 QPS 接近实例上限，而 并发连接数 很低 → 问题在于突发流量高峰或短连接频繁创建。需要优化后端响应速度，或升级实例规格以提升 QPS 处理能力。
-
观察 TIME_WAIT 状态：
- 在后端服务器上执行
netstat -an | grep TIME_WAIT，如果发现大量 TIME_WAIT 连接，说明客户端频繁建连断连，导致资源浪费。此时应启用 HTTP Keep-Alive，从而降低并发连接数，提高 QPS 效率。
- 在后端服务器上执行
-
成本优化建议：
- 对于高 QPS 低并发的场景（如电商秒杀），选择支持高 QPS 的 ALB 实例更划算。
- 对于高并发低 QPS 的场景（如游戏服务器、IoT 设备上报），选择支持高并发连接的 NLB 或 CLB 实例更合适。
5. 总结
| 维度 | 并发连接数 | 每秒请求数 (QPS) |
|---|---|---|
| 层级 | 传输层 (TCP) 为主 | 应用层 (HTTP) 为主 |
| 含义 | 同一时刻存在的活跃连接数 | 每秒完成的 HTTP 请求次数 |
| 影响因素 | 连接生命周期、Keep-Alive、超时设置 | 请求频率、页面复杂度、缓存命中率 |
| 典型比值 | 长连接业务：连接数 >> QPS 短连接业务：连接数 ≈ QPS |
短连接业务：QPS ≈ 连接数 长连接业务：QPS << 连接数 |
| 瓶颈表现 | “Too Many Connections” 错误 | “Request Timeout” 或 502 Bad Gateway |
结论：
并发连接数反映的是系统的负载压力（有多少人在连着），QPS 反映的是系统的吞吐能力（每秒处理多少事）。在现代 Web 架构中，通过合理配置 Keep-Alive，可以用较少的并发连接数支撑更高的 QPS，从而实现更好的资源利用率。