轮询调度不提升处理能力上限，而是通过有序分发请求实现资源均衡利用，避免单点过载；适用于无状态、响应相近的服务，需配置健康检查、连接复用和真实ip透传，遇性能差异、会话依赖或长连接场景应切换为加权轮询、ip_hash或least_conn算法。
轮询调度本身不直接“提高”集群的处理能力上限，而是让现有服务器资源被更公平、更有序地利用，从而在不增加硬件的前提下，提升整体吞吐稳定性与服务可用性。它解决的是请求分配的秩序问题，不是算力扩容问题。
轮询怎么让集群跑得更稳
默认按顺序把请求分给后端服务器（A→B→C→A…），避免某台机器瞬间被打满而其他空闲。这种线性分发天然适合无状态、响应时间相近的服务，比如静态文件服务或轻量 API 接口。只要后端节点性能接近，轮询就能让每台机器的 CPU、内存占用趋于均衡，减少单点过载风险。
配置简单但不能裸用
只写几行 upstream 就能启用轮询，但生产环境必须补上基础健壮性措施：
- 加上 max_fails=3 fail_timeout=30s，让 Nginx 在连续失败后暂时跳过故障节点，避免请求持续打到已宕机的机器上
- 开启 keepalive 32 复用后端连接，降低 TCP 握手开销，尤其对高频短连接场景效果明显
- 务必设置 proxy_set_header X-Real-IP $remote_addr，确保后端日志和限流能识别真实客户端，而不是 Nginx 的内网 IP
什么时候该换别的算法
轮询的公平是“次数公平”，不是“负载公平”。遇到这些情况就得考虑替代方案：
- 新旧服务器混用——CPU 性能差 2 倍，还用轮询会导致旧机 CPU 长期 95%+，此时改用加权轮询（weight=1 vs weight=2）更合理
- 服务有会话依赖（如登录态存在内存里）——轮询会让用户反复跳机器，丢失上下文，应切换为 ip_hash
- 后端存在大量长连接或耗时任务（如文件上传、报表导出）——轮询不看当前连接数，容易堆积，建议配合 least_conn
验证轮询是否真在起作用
别只看配置有没有生效，要实测流量走向：
- 用循环命令快速发起多个请求：for i in {1..6}; do curl http://your-nginx-ip; echo; done
- 观察返回结果是否严格按后端顺序交替出现（server1→server2→server3→server1…）
- 配合后端 access 日志或 curl -v 查看 X-Upstream-Addr 头（需提前在 proxy_pass 前加 proxy_set_header X-Upstream-Addr $upstream_addr）
