Nginx 中最少连接策略实现高并发下的负载平滑

最少连接策略（least_conn）在Nginx中实时选择当前活跃连接数最少的后端服务器，专注连接数这一即时指标，适合高并发、长连接及处理时长差异大的场景，能动态避让满负荷节点、抑制热点、降低尾部延迟。

最少连接策略（least_conn）在 Nginx 中不是靠预估或统计历史负载，而是实时查看各后端服务器当前活跃连接数，把新请求发给此刻连接数最少的那台。它不关心响应快慢、CPU 占用或内存使用，只盯住“正在处理的连接数量”这个即时指标——这恰恰让它在高并发、长连接、处理时长差异大的场景下，比轮询更平滑、更抗压。

为什么最少连接更适合高并发下的负载平滑

轮询按顺序派发，容易造成“请求堆积在慢节点”。比如一台后端处理一个请求要 2 秒，另一台只要 200 毫秒，轮询仍会平均分配，结果慢节点连接越积越多。而最少连接策略能动态避开已满负荷的节点，天然抑制热点形成。

1. 对长连接友好：WebSocket、HTTP/2 流、文件上传等场景中，单连接持续时间长，连接数比请求数更能反映真实压力
2. 自动适配性能差异：无需人工设权重，新旧服务器混用时也能自发平衡
3. 降低尾部延迟：避免把请求塞进已排队的节点，整体 P95/P99 延迟更稳定

配置要点与常见误区

最少连接策略启用简单，但效果依赖合理的基础配置。光写 least_conn 不够，还需注意几个关键点：

1. upstream 块中必须显式声明：least_conn;，否则默认是轮询
2. 确保后端服务正确关闭空闲连接（如设置 keepalive_timeout），否则连接数长期不释放，策略会失效
3. 配合 max_conns 限制单台最大连接数，防止某台机器被突发流量打穿（例如：server 192.168.1.101 max_conns=1024;）
4. 不建议与 ip_hash 或 hash $request_uri 同时启用，二者逻辑冲突

搭配健康检查提升稳定性

最少连接本身不判断后端是否存活。若某台服务器网络断开但连接未超时，Nginx 仍可能把它当作“连接数少”的可用节点继续转发，导致请求失败。因此务必开启主动健康检查：

1. 使用 health_check 指令（需 stream 或 http 模块支持）定期探测后端 HTTP 状态码
2. 或结合 max_fails 和 fail_timeout，让 Nginx 在连续失败后临时剔除异常节点
3. 推荐组合：least_conn + max_fails=3 fail_timeout=30s + health_check interval=5s fails=2 passes=2

性能表现与适用边界

实测数据显示，在后端处理耗时不均的典型 Web API 场景下，least_conn 相比轮询可提升约 40% 的吞吐量，P99 延迟下降明显。但它也有局限：

1. 不适合极短连接（如毫秒级静态资源请求），此时连接数变化太快，统计意义减弱
2. 无法感知 CPU、磁盘 I/O 等系统级瓶颈，仅反映连接层负载
3. 在连接数极低（如每秒几请求）时，和轮询差异几乎不可测