least_conn调度策略在突发流量下更稳，因其将请求实时导向活跃连接数最少的健康节点，避免轮询导致的负载不均；需配置least_conn声明、max_fails/fail_timeout、被动健康检查及keepalive复用，并叠加限流与缓冲机制。
最少连接（least_conn）调度策略在应对突发流量时效果显著，但前提是配置完整、后端配合到位。它不靠预设权重或固定轮序，而是实时把新请求导向当前活跃连接数最少的健康节点——这对响应时间波动大、计算密集型或含长连接的场景特别管用。
为什么突发流量下 least_conn 更稳
轮询策略会平均分发请求，不管某台后端是否正处理耗时任务；而 least_conn 能主动避开已堆积连接的节点。比如秒杀开始瞬间涌入 500 请求，若某台后端因 GC 暂停卡住，其连接数快速上升，least_conn 会自动将后续请求导给空闲节点，避免雪崩式延迟累积。
必须配齐的四个关键项
- upstream 块中显式声明 least_conn，不能只依赖默认行为
- 每个 server 行配 max_fails 和 fail_timeout，例如
max_fails=2 fail_timeout=15s，让 Nginx 主动剔除异常节点 - 启用被动健康检查：通过 proxy_next_upstream error timeout http_500 http_502 配合 max_fails 生效；有条件建议加主动 health_check
- 上游开启 keepalive 连接复用，如
keepalive 32;，并确保后端服务也支持连接池，否则连接数统计失真
搭配限流与缓冲更可靠
least_conn 解决“往哪发”，但不控制“发多少”和“怎么收”。突发流量下还需叠加：
-
limit_req 做速率控制，比如
limit_req zone=burst burst=50 nodelay，防请求洪峰直接冲垮后端队列 - proxy_buffering on + 合理 buffer 大小，避免上游响应慢时 worker 被阻塞
- keepalive_timeout 和 keepalive_requests 缩短长连接生命周期，加快连接回收
验证是否真生效
别只看日志或平均延迟。要监控：
- 各后端的 active connections 是否均衡（可用 stub_status 或 Prometheus 抓取）
- $upstream_header_time 和 $upstream_response_time 的分离趋势：前者稳、后者升，说明问题在后端逻辑；两者同步升，可能是 Nginx 层瓶颈或 least_conn 没起作用
- 观察 $upstream_addr 分布，确认请求确实落在连接数低的节点上，而非因健康检查失效导致“假均衡”
