轮询调度不提升集群绝对处理能力，而是通过均衡分发请求减少单点过载、提升响应稳定性与可用率；它适用于服务器性能相近、无状态、响应时间稳定的场景，具备低开销、高确定性、配置极简、无状态友好、可预测性强等优势。
轮询调度本身不提升集群的绝对处理能力上限，而是让多台后端服务器被更均衡、更有序地使用，从而在不加机器的前提下，减少单点过载、提升整体响应稳定性和服务可用率。它解决的是请求“怎么分”的问题，不是“怎么变强”的问题。
轮询为什么适合大型集群的基础层
在服务器性能相近、业务无状态（比如静态资源、轻量API）、响应时间波动小的场景下，轮询天然具备低开销、高确定性的优势。请求按 A→B→C→A… 的顺序线性分发，每台机器接收的请求数基本一致，CPU 和内存占用更容易维持在合理区间，避免某台突然打满而其他空闲。
- 配置极简：只需定义 upstream 块，不写算法即默认启用
- 无状态友好：不依赖客户端信息或后端连接状态，扩展性好
- 可预测性强：便于容量规划和压测结果比对
裸用轮询在大型集群里容易踩的坑
生产环境尤其是大型集群中，轮询不能只写几行 server 就上线。必须补上三项基础健壮性措施：
-
健康检查：加上
max_fails=3 fail_timeout=30s，自动剔除失联或响应超时的节点，防止流量持续打到故障机 -
连接复用：配置
proxy_http_version 1.1; proxy_set_header Connection '';，复用后端长连接，显著降低高频短连接下的 TCP 握手与 TIME_WAIT 压力 -
真实IP透传：务必设置
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For，否则后端日志、限流、风控都只能看到 Nginx 内网 IP
什么时候该主动换掉轮询
轮询的公平是“次数公平”，不是“负载公平”。当集群出现以下特征时，需切换更匹配的算法：
- 新旧机型混用，CPU 性能相差 2 倍以上 → 改用加权轮询（如新机 weight=4，旧机 weight=1）
- 会话数据存在本地内存（如未接入 Redis 的登录态）→ 切换为ip_hash，保证同一用户始终落在同一台
- 大量文件上传、报表导出、WebSocket 长连接 → 启用least_conn，优先分给当前连接数最少的节点
怎么验证轮询真正在生效
别只看配置有没有语法错误，要实测流量走向：
- 用循环命令快速发起 6 次请求：
for i in {1..6}; do curl http://your-domain; echo; done - 观察返回标识（如后端返回 server-id 或 host 名）是否严格按顺序交替出现
- 配合后端 access.log 查看每台机器的实际请求时间戳分布，确认无明显倾斜
