Nginx轮询本身不支持按需转发，仅静态均分流量；可通过weight实现粗粒度权重分配、健康检查实现异常节点避让，或借助外部系统（如Prometheus、Consul、OpenResty+Lua）实现真正按需调度。
Nginx 的轮询（Round Robin）调度本身是静态均分流量的，不直接支持“按需转发”——也就是说，它不会根据后端负载、响应时间或实时请求数自动调整分发权重。但可以通过组合配置和外部机制，让轮询行为更贴近“按需”效果。
基础轮询：默认行为与局限
Nginx upstream 默认使用轮询策略，每个请求依次分发给后端服务器，不考虑节点当前状态。例如：
upstream backend {server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
这种配置下，三台服务器收到的请求数理论上严格相等，即使其中一台已过载或响应变慢。它不是“按需”，而是“按序”。
用 weight 实现粗粒度按需分配
通过 weight 参数可为不同后端设置相对权重，间接反映其处理能力差异：
- 性能强的机器设更高 weight（如
weight=3），弱机设低值（如weight=1） - 权重仅在初始化时生效，运行中无法动态调整
- 适合长期稳定的容量差异场景，比如新旧服务器混用
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
结合健康检查 + max_fails/fail_timeout 提升可用性
虽然不是动态调权，但可通过自动摘除异常节点，让剩余节点承担更多流量，形成事实上的“按需避让”：
- max_fails=2 表示连续失败 2 次即标记为不可用
- fail_timeout=30s 表示 30 秒内不向该节点转发请求
- 配合
health_check（需 stream 模块或商业版）可实现主动探测
server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=2 fail_timeout=30s;
}
真正按需：需外接控制逻辑
若要实现基于 CPU、QPS、延迟等指标的实时调度，Nginx 原生轮询无法胜任，需引入外部协调层：
- 用 Prometheus + Alertmanager 监控后端指标，触发脚本更新 Nginx upstream 配置并 reload
- 使用 Consul + nginx-upsync-module 动态维护 upstream 列表（开源方案）
- 接入 OpenResty，用 Lua 在 balancer_by_lua_block 中自定义调度逻辑（如依据 header、cookie 或上游响应头动态选节点）
这类方案已超出传统轮询范畴，本质是用 Nginx 作为执行终端，决策由外部系统完成。
