轮询适合响应时间均匀的无状态服务，按顺序分发请求且开销低；最少连接适合响应时间差异大的场景，动态分配至活跃连接最少的服务器，可显著降低尾部延迟。
轮询和最少连接是 Nginx 最常用的两种负载均衡策略，它们在性能表现上差异明显，关键看后端服务的响应特性是否稳定。
轮询策略适合请求耗时均匀的场景
轮询按顺序把请求分给每台服务器，不关心当前负载状态。它实现简单、开销极低，CPU 和内存占用几乎可以忽略。但如果后端节点处理能力不同或请求耗时波动大（比如有的接口要查数据库、有的只是返回静态 JSON），就会出现“分配了请求，但那台机器还在忙”的情况，导致部分服务器堆积连接，整体响应变慢。
- 默认启用，无需额外配置
- 适用于后端服务响应时间相近、无明显长耗时操作的 API 或静态资源服务
- 配合 weight 可做粗粒度流量倾斜（如新旧机器混用）
最少连接策略更适合响应时间差异大的服务
least_conn 动态感知每台后端的活跃连接数，新请求总是发给当前连接最少的机器。这能有效避免“忙的更忙、闲的更闲”，特别适合混合型业务：比如一个集群里既有毫秒级的鉴权接口，也有几秒甚至十几秒的报表导出任务。
- 需要实时维护连接计数，有轻微运行时开销（但现代 Nginx 版本已高度优化）
- 对突发流量或短连接密集型服务（如 HTTP/1.1 短连接）效果显著
- 若后端存在连接泄漏或异常断连未及时释放，可能影响调度准确性
实际性能差异取决于后端稳定性
当所有后端节点健康且响应时间标准差小于 20% 时，轮询吞吐量通常略高（约 3%–5%），因为省去了连接数查询和比较逻辑；一旦响应时间离散度上升（例如标准差超过 50%），least_conn 的平均延迟可比轮询低 30% 以上，尤其体现在 P95/P99 延迟指标上。
- 建议用真实流量压测对比：同一组后端，分别切流 10% 流量跑两套 upstream 配置
- 关注指标不只是 QPS，更要盯住后端连接数分布、5xx 比率和尾部延迟
- 生产环境常将 least_conn 与 health_check 结合使用，防止故障节点持续接收新连接
不推荐单纯靠理论选型
轮询不是“低端”，least_conn 也不是“万能”。很多高并发系统用加权轮询搭配合理的扩容节奏，比盲目切 least_conn 更稳；而一些微服务网关在引入 gRPC 长连接后，least_conn 的优势反而被削弱——此时连接数不再准确反映真实负载。选型必须结合协议类型、超时设置、后端健康机制一起看。
