轮询调度不提升硬件上限，而是通过均匀分发请求使集群承载能力逼近各节点之和；需后端性能相近、无状态，配合健康检查、keepalive及合理配置才能发挥实效。
轮询调度本身不直接“提升”硬件承载上限，而是让现有后端服务器的资源被更均匀、更持续地利用，从而逼近理论最大吞吐量。它不增加算力，但能显著减少空转和局部过载，使集群整体承载能力更接近各节点能力之和。
让每台后端都跑在合理负载区间
轮询按顺序把请求分发到各节点，前提是后端性能相近、无状态。这样避免了某台机器因随机或固定路由被持续打满，而其他机器闲置的情况。三台同等配置的服务器，在轮询下可稳定承载接近单台3倍的并发量——前提是连接管理、超时、健康检查等配套到位。
- 若某台后端响应慢或卡住，轮询会继续向它派发新请求，造成雪崩；必须配合max_fails=3 fail_timeout=30s自动隔离故障节点
- 默认不校验后端真实负载，仅靠“顺序”分配；因此要求各节点部署一致、扩容需同步，否则易失衡
- 适合短连接、轻计算类服务（如静态资源、RESTful API），不适合长连接或状态强依赖场景
降低连接与上下文开销，释放并发余量
轮询本身轻量，无哈希计算、无连接数统计，执行开销几乎为零。这使得Nginx worker能将更多CPU和内存用于实际代理转发，而非调度决策。配合KeepAlive复用连接后，建连/断连损耗大幅下降，单位时间可处理更多请求。
- 在upstream中加keepalive 32，复用到后端的TCP连接，避免每次请求新建连接
- 在location中配proxy_http_version 1.1和proxy_set_header Connection ""，确保后端也复用连接
- 客户端侧保持Connection: keep-alive头，否则轮询效果会被频繁重连抵消
配合基础容错，保障集群可用容量不缩水
生产环境中，一台后端短暂不可用是常态。轮询若无健康检查，会持续把请求打向宕机节点，导致大量超时、重试和用户感知卡顿——这等于变相降低了集群有效承载量。通过内置参数实现快速摘除，才能维持标称容量。
- max_fails和fail_timeout组合使用，30秒内连续失败3次即临时剔除，恢复后自动回归
- 搭配backup标记备用节点，主节点全挂时仍可降级承接流量，避免容量归零
- 避免手动用down长期屏蔽节点，否则轮询权重失衡，剩余节点可能过载
验证是否真正发挥了轮询价值
不能只看配置写了server列表，要确认请求确实均匀落到各后端。常见干扰包括浏览器缓存、CDN缓存、客户端重试机制，建议用curl循环直连Nginx，并比对后端访问日志或返回标识。
- 执行for i in {1..9}; do curl http://nginx-ip; done，观察返回是否呈现A→B→C→A→B→C规律
- 在每台后端加唯一响应头（如X-Server-ID: node-a），便于快速定位分发路径
- 用nginx -t && systemctl reload nginx确保配置生效，避免reload失败却误以为已上线
