轮询调度算法不直接优化响应延迟，仅按顺序分发请求，不感知后端响应快慢；仅在后端性能一致、请求处理时间相近时，通过均匀分配间接维持稳定延迟，否则可能放大延迟毛刺。
轮询调度算法本身不直接改善响应延迟，它只是按顺序分发请求，不感知后端响应快慢。在后端性能高度一致、请求处理时间相近的前提下，轮询能避免单点过载，间接维持较低且稳定的平均延迟；但一旦存在响应时间差异，轮询反而可能放大延迟问题。
轮询对延迟“无感”，只管顺序分发
轮询在连接建立前就选定后端，不参考响应时间、连接数或实时负载。哪怕某台服务器响应已超 2s，只要没触发健康检查失败，下个请求仍会照常轮到它。这意味着：
- 无法避开慢节点，延迟毛刺会真实传递给用户
- 没有动态反馈机制，不能根据实际耗时调整调度倾向
- 长连接场景下，worker 进程可能长时间绑定高延迟实例，加剧感知延迟
什么情况下轮询看似“压低了延迟”
仅当满足以下全部条件时，轮询才可能表现出较优的延迟稳定性：
- 所有后端实例硬件配置、部署环境、JVM/运行时参数完全一致
- 业务逻辑轻量且执行时间方差极小（如简单鉴权、透传代理）
- 网络 RTT 均匀，无跨机房或专线抖动
- 启用了
max_fails/fail_timeout主动剔除明显异常节点
此时轮询的“均匀性”可防止某台机器因突发流量堆积请求队列，从而避免延迟陡增——但这属于被动规避，不是主动优化。
响应延迟敏感时，该换更合适的算法
若监控发现 P95 延迟波动大、各 upstream 实例间 RT 差异持续超过 200ms，说明轮询已不适用。可考虑：
- least_conn：适合长连接或处理耗时不均的服务（如 WebSocket、订单创建），优先选当前连接数少的节点，减少排队等待
- least_time（Nginx Plus）：综合平均响应时间和活跃连接数，真正向“快且空闲”的节点倾斜
-
自定义 Lua 调度：基于上游返回头（如
X-Response-Time）实时调整权重，实现闭环反馈
用好轮询，得靠配套配置兜底
即使坚持用轮询，也要通过以下手段缓解延迟风险：
- 为每个
server显式写weight=1，防止继承意外值 - 配
max_fails=2 fail_timeout=15s，快速隔离响应超时或失败的实例 - 启用
keepalive 32和keepalive_requests 1000，复用连接、减少 TCP 握手开销 - 设置合理的
proxy_read_timeout和proxy_next_upstream timeout http_500，及时切走失败请求
