Nginx 最少连接调度提升后端集群任务处理效能

最少连接调度（least_conn）要求连接数真实反映后端负载，必须同时满足：upstream中声明least_conn、server配置max_fails和fail_timeout、启用proxy_next_upstream被动检查、upstream开启keepalive且后端支持长连接。

最少连接调度（least_conn）不是“挑个空闲节点凑合用”，而是让 Nginx 在请求到达瞬间，从所有健康后端里选出当前活跃连接数最少的那个——它真正起效的前提，是连接数能真实反映后端负载。

必须配齐的四个基础项

光写 least_conn 这一行配置，几乎没用。以下四点缺一不可：

1. upstream 块中明确声明 least_conn，否则默认走轮询
2. 每个 server 行必须带 max_fails=2 fail_timeout=15s，否则宕机节点仍持续收请求
3. 启用被动健康检查：在 location 或 upstream 外层配置 proxy_next_upstream error timeout http_500 http_502
4. upstream 内开启连接复用：keepalive 32，同时后端服务需支持长连接（如 Tomcat 设置 maxKeepAliveRequests）

连接数要“准”，才调度得对

活跃连接数不准，least_conn 就变成随机分发。常见干扰来源有两个：

1. 后端维持大量空闲长连接却不释放，导致连接数虚高——可通过减小 keepalive 值（如设为 16）或加 proxy_http_version 1.1; proxy_set_header Connection ''; 让 Nginx 主动管理连接生命周期
2. 短连接高频建连断连，连接刚建立就关闭，统计窗口内连接数跳变剧烈——此时建议搭配 weight 参数，给性能更强的机器更高权重，避免小规格节点被频繁选中却撑不住

监控要看组合指标，不能只盯一个数

单看 $upstream_addr 日志只能知道落到哪台机器，无法判断调度是否合理：

1. 用 stub_status 或 Prometheus exporter 查各后端的 active connections，若某台长期接近 worker_connections 上限，说明已到瓶颈，算法再准也无济于事
2. 对比 $upstream_header_time 和 $upstream_response_time：前者稳定、后者飙升，问题在后端逻辑；两者同步升高，可能是 Nginx 自身连接池不足或网络延迟突增
3. 加日志字段 $upstream_cache_status，排除因缓存失效引发的重复计算压力，尤其在模型推理类服务中很关键

适合场景与明显不适用的情况

least_conn 对以下情况提升显著：

1. 请求处理时间差异大（比如 100ms 的普通接口混着 8 秒的 AI 推理）
2. 存在长连接（WebSocket、SSE、文件上传等），连接生命周期远超请求处理时间
3. 后端资源（CPU/内存）不均，但可通过 weight 显式表达差异

但它不适合：

1. 所有后端响应时间高度一致且极短（如毫秒级键值查询），此时轮询更稳定
2. 后端本身无连接状态管理（例如无状态函数计算 FaaS），连接数失去参考意义
3. 网络抖动频繁、超时阈值过松，导致健康检查失效，least_conn 会把请求持续打向不稳定节点