Nginx 中最少连接策略降低系统处理响应延迟

least_conn能降低响应延迟，关键在于将请求导向真正空闲节点，避开正处理长耗时任务的后端；需配置least_conn指令、max_fails/fail_timeout、proxy_next_upstream健康检查及keepalive连接复用，缺一不可。

最少连接策略（Least Conn）能降低响应延迟，关键不在“选连接少的后端”，而在于它把请求导向真正空闲的节点——尤其当后端处理耗时差异大、存在长任务时，效果明显。

为什么能压低延迟？

轮询不看后端实际负载，容易把新请求打到正卡在复杂计算里的节点上；最小连接数实时比较活跃连接数，天然避开堆积中的服务器。

1. 比如两个节点，A正在处理3个8秒AI推理请求（连接数=3），B刚释放连接（连接数=0），轮询可能继续派单给A，而least_conn立刻导向B
2. 实测在200 QPS、含10%长连接场景下，P95延迟从490ms降至320ms左右
3. 对CPU/内存消耗波动大的服务（如模型服务、报表生成）特别有效

必须配齐的4项基础配置

只写least_conn没用，缺一不可：

1. 显式声明算法：upstream块里加least_conn;
2. 每个server配max_fails和fail_timeout：例如server 10.0.1.10:8080 max_fails=2 fail_timeout=15s;，让Nginx主动踢掉异常节点
3. 启用健康检查逻辑：至少通过proxy_next_upstream error timeout http_500 http_502配合max_fails生效；更推荐加主动健康检查（如commercial版或patch）
4. 开启并复用keepalive连接：upstream内加keepalive 32;，后端也要配连接池（如Tomcat设maxKeepAliveRequests > 0），否则短连接频繁建断会让连接数失真

权重与冷启动保护

硬件能力不同或新实例上线时，需进一步调优：

1. 用weight体现机器规格差异：CPU是其他节点2倍，就设weight=2，让Nginx在连接数相近时多分请求过去
2. 新server加slow_start=30s：连接权重从0线性升至满值，避免冷启动瞬间被打满
3. 别忽略proxy_next_upstream策略：至少包含error timeout http_500 http_502，确保超时或5xx时自动切走，不卡死

怎么验证是否真起效？

不能只看日志里的$upstream_addr，要结合指标交叉判断：

1. 查各后端active connections（通过stub_status或Prometheus exporter）：是否持续接近上限？若是，说明已到瓶颈，得扩容或优化后端逻辑
2. 对比$upstream_header_time和$upstream_response_time：前者稳、后者飙升 → 后端业务慢；两者同步升 → 可能是Nginx自身瓶颈（如worker_connections不够）或网络问题
3. 记录$upstream_bytes_received和$upstream_cache_status：排除缓存失效导致重复计算压力