轮询是Nginx默认且开销最低的负载均衡算法，仅通过轻量计数器取模实现请求分发，CPU占用稳定可预测，适用于后端性能相近、无状态的服务场景。
轮询是 Nginx 默认且开销最低的负载均衡算法，它不依赖状态判断或复杂计算，仅靠轻量计数器实现请求分发，在绝大多数生产场景中 CPU 占用稳定、可预测。
轮询的底层执行非常轻量
每次请求到来时，Nginx 仅需递增一个整数计数器，并对后端服务器总数取模，整个过程在 CPU 指令级完成，无内存分配、无分支跳转、无锁竞争。即使在 10k+ RPS 的高并发下，单个 worker 进程的 CPU 使用率通常维持在 5%～15% 区间，远低于其他策略。
- 加权轮询虽引入 weight 累加逻辑，但仍在 O(1) 时间内完成，实际性能损耗几乎不可测
- 避免无意义地显式配置 weight=1，否则会强制走加权路径，徒增微小但不必要的计算
- 不维护连接数、响应时间等运行时状态，无共享内存读写或原子操作开销
对比其他算法，轮询优势明显
当后端节点性能相近、服务无状态时，轮询不仅足够公平，而且资源效率最优。相比之下：
- ip_hash 需对客户端 IP 做哈希运算（IPv6 还要截位），万级 QPS 下哈希计算可能吃掉 8%～20% 的 worker CPU
- hash $request_uri 每次都要遍历 URI 字符串，长路径或含查询参数时开销进一步放大
- least_time 依赖共享内存区统计响应时间，每次选节点都触发原子读 + 自旋锁等待，多核高并发下 sys CPU 明显升高
适用边界与注意事项
轮询不是万能的，它的低开销建立在“假设后端处理能力一致”前提上。若出现以下情况，需谨慎评估：
- 后端服务器硬件差异大（如 4C8G 与 16C32G 混部），轮询会导致弱节点更快饱和
- 请求处理耗时不均（如部分接口涉及数据库慢查询），轮询无法规避积压风险
- 需要会话保持（如登录态绑定），轮询本身不提供粘性，必须配合其他机制（如 cookie 或前端重试）
实测建议与调优方向
若当前使用轮询且观察到 CPU 异常升高，优先排查是否误启了高开销策略，而非优化轮询本身：
- 检查 upstream 块是否混用了 ip_hash、hash 或 least_conn 等指令
- 确认未启用第三方模块（如 upstream_fair），它们往往带来额外解析与调度负担
- 监控 nginx_stub_status 中 active connections 分布，验证是否真为均衡——不均衡未必是算法问题，可能是后端响应延迟或超时设置不合理
