Nginx 中最少连接算法降低后端连接并发冲突率

最少连接算法（least_conn）通过将请求导向当前连接数最少的后端节点来降低并发冲突率，它依赖实时连接数这一真实压力指标，尤其适用于长连接与响应时间差异大的场景，并需配合健康检查、upstream keepalive及后端连接复用配置才能生效。

最少连接算法（least_conn）能有效降低后端连接并发冲突率，关键在于它把请求导向“当前最空闲”的节点，而不是按顺序或随机分配。它不依赖预测，只看实时连接数——这个数字直接反映后端是否正在被长任务占用、是否已接近连接瓶颈。

为什么能减少并发冲突

并发冲突常源于多个请求同时挤向同一台正处理慢任务的后端，比如一个 5 秒的报表导出还没结束，新请求又持续打过去，导致连接堆积、队列拉长、超时频发。least_conn 从源头规避这个问题：

1. 连接数是真实压力指标：每个未关闭的 TCP 连接代表一个尚未完成的事务，统计它比轮询更贴近后端实际负载
2. 长连接场景下优势明显：WebSocket、HTTP/2 流、大文件上传等会让单连接长期存活，least_conn 能识别这种“隐性占用”，而轮询完全无感
3. 响应时间差异大时更公平：毫秒级查询和 10 秒级计算混跑时，least_conn 自然绕开卡住的节点，避免雪崩式堆积

必须配合的三项配置

单独写 least_conn 不足以生效，以下三项缺一不可：

1. 启用健康检查：用 max_fails=2 fail_timeout=15s 或主动 health_check，否则宕机但连接未断的节点仍会被选中，反而加剧失败重试
2. 开启 upstream keepalive：例如 keepalive 32，让 Nginx 复用后端空闲连接；否则短连接频繁建连断连，连接数波动剧烈，least_conn 判断失真
3. 后端需支持连接复用：如 Tomcat 设置 maxKeepAliveRequests，Node.js 启用 keepAliveTimeout，否则 Nginx 的 keepalive 无法落地

用 max_conns 体现节点真实容量

least_conn 本身不认 weight，但可通过 max_conns 实现软性限流，让高配机器多扛压、低配机器不超载：

1. 高性能节点设 server 192.168.1.10:8080 max_conns=2000
2. 普通节点设 server 192.168.1.11:8080 max_conns=800
3. 当某节点活跃连接数达到 max_conns，Nginx 会跳过它，即使它当前连接数仍略低于其他节点

这比单纯靠连接数排序更精细，尤其适合混合部署场景。

验证是否真正起效

别只看日志，要结合监控确认算法在“看清真实负载”：

1. 通过 stub_status 或 Prometheus 指标观察各后端 active connections 是否均衡（波动范围建议控制在 ±20% 内）
2. 对比 $upstream_connect_time 和 $upstream_header_time：前者稳定但后者飙升，说明问题在后端业务逻辑，不是负载策略失效
3. 检查 $upstream_addr 分布是否随连接数动态偏移——如果某台始终高频出现，大概率是健康检查没生效或 keepalive 未复用