轮询算法为后端集群平滑扩容提供最简基础：新增无状态、性能一致的节点只需追加server配置并重载，即刻参与均等调度；需配合健康检查与连接复用以保障可用性与效率。
轮询算法本身不直接增强后端集群的扩展性，但它为平滑扩容提供了最友好的基础结构——只要新增节点性能相近、无状态且部署一致，就能被立即纳入调度循环，无需改配置、不引入额外计算开销。
新增节点即刻生效，无需权重调优
轮询默认按声明顺序依次分发请求，新加入的 server 只需写进 upstream 块，Nginx 重启或重载后自动参与轮转。不像加权轮询需反复试算 weight，也不像 least_conn 或 ip_hash 需额外模块或状态同步，扩容操作极简。
- 三台变四台？只需追加一行
server 192.168.1.104:80; - 所有节点默认权重为 1，天然“一视同仁”，避免人为误配导致流量倾斜
- 适合 CI/CD 自动化部署：脚本生成 upstream 配置时，无需动态计算权重或校验负载差异
横向扩容效果可预期，前提是节点能力对齐
当新增节点与原有节点 CPU、内存、网络、应用响应时间基本一致时，轮询能让总承载量线性逼近 N×单节点容量。比如原三台服务器稳定支撑 3000 QPS，新增一台同等配置后，理想状态下可达约 4000 QPS。
- 扩容后每台机器请求量下降，平均响应延迟更稳，毛刺减少
- 若新节点性能明显偏弱（如旧型号物理机混入），反而会拖慢整体吞吐，此时应改用加权轮询并设低 weight
- 节点间部署不一致（如某台缺缓存、某台版本滞后）会导致实际处理耗时差异，轮询无法感知，需靠发布流程统一保障
配合健康检查，让扩容真正“可用”
扩容不是加完 server 就结束。若新节点上线后因配置错误或依赖未就绪而响应超时，轮询仍会持续派发请求，造成局部失败率上升，抵消扩容收益。
- 必须启用
max_fails=2 fail_timeout=15s，快速隔离异常节点，保障其余节点不受影响 - 建议搭配主动健康检查（
health_check指令，需 Plus 或开源版 1.25+）定期探测 /health 端点，比被动失败更早发现问题 - 灰度发布时，可先将新节点标记为
backup，验证稳定后再移除该标记，避免全量切流风险
连接复用降低扩容边际成本
轮询调度开销近乎为零，但高频短连接场景下，建连耗时会成为扩容瓶颈。启用 keepalive 后，Nginx 到后端的连接可复用，使得新增节点能更快承接真实业务流量，而非卡在 TCP 握手上。
- upstream 中加
keepalive 32;，维持最多 32 个空闲长连接 - location 中设
proxy_http_version 1.1;和proxy_set_header Connection "";，确保 HTTP/1.1 连接复用生效 - 客户端保持
Connection: keep-alive，否则每次请求重建连接，轮询带来的均衡优势会被网络开销稀释
