轮询调度需搭配健康检查、连接复用、真实IP透传三项容错机制，并按实测吞吐量设置合理权重，识别长连接、本地会话、低延迟等场景及时切换算法，通过多维度验证确保生效。
轮询调度本身不提升集群处理上限，但能让请求更稳、更均匀地落到各节点上。在动态集群中，单纯靠默认轮询容易失效——后端性能波动、连接堆积、状态依赖都会让“顺序分发”变成“盲目分发”。优化重点不是换算法，而是让轮询更贴合真实运行状态。
补全三项基础容错机制
裸用轮询等于把调度权交给运气。必须加装三道保险：
-
主动健康检查：加上
max_fails=3 fail_timeout=30s，节点连续失败3次就摘除30秒，避免流量持续打到卡死或超时的机器 -
连接复用：配置
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 内网地址，失去上下文
按硬件差异启用加权轮询
新旧服务器混用时，“平均分配”就是最大不公平。权重不能拍脑袋定，要基于实测吞吐量反推：
- 比如压测发现新节点 QPS 达 1200，旧节点仅 600，就设
weight=2和weight=1 - 避免极端比例（如 weight=100 和 weight=1），否则小权重节点长期闲置，冗余能力形同虚设
- 权重不是百分比，是相对值；每轮分发基数由所有权重之和决定
识别不适用场景，及时切换算法
轮询只保证“次数公平”，不保证“负载公平”。出现以下情况，就得主动替换：
- 大量文件上传、报表导出或 WebSocket 长连接 → 改用
least_conn，优先分给当前活跃连接最少的节点 - 用户登录态存在本地内存（未接入 Redis）→ 切换为
hash $cookie_sessionid，比ip_hash更精准，避开 NAT 环境失真问题 - 搜索建议、风控接口等对延迟极度敏感 → 可引入
fair模块，或用 OpenResty + Lua 实现响应时间驱动的自适应路由
验证是否真正在生效
别只看配置有没有语法错误，要实测流量走向：
- 用循环命令快速发起 6 次请求，观察返回的 server-id 或 host 名是否严格按顺序交替出现
- 结合 Prometheus + Grafana 监控各后端的
request_time、错误率、连接数，确认无明显倾斜或积压 - 查 Nginx 日志中的
$upstream_addr字段，统计各节点实际承接请求数占比，与理论权重比对
