轮询策略是nginx默认负载均衡方式，按顺序依次分发请求，结构简单、天然公平、无状态、支持故障规避，但忽略性能差异、不感知实时负载、无会话粘性，适用于静态资源、无状态微服务等场景。
轮询策略是 Nginx 默认的负载均衡方式，无需额外配置即可启用，核心逻辑就是按顺序把请求依次分发给后端服务器。它不依赖状态记录、不计算实时负载，因此开销极低、稳定性高，适合大多数基础场景。
轮询策略的核心优点
结构简单，部署零门槛：只要在 upstream 块中列出服务器地址，Nginx 就自动启用轮询，连 weight 或 ip_hash 都不用写。
天然公平，长期请求分布均匀：假设有三台服务器 A、B、C，第1个请求到 A，第2个到 B，第3个到 C，第4个又回到 A……循环往复，理论上每台服务器承接请求数趋近一致。
无状态设计，不增加代理层负担：不需要维护连接数、响应时间或客户端 IP 映射表，内存占用小，吞吐能力强，特别适合高并发但单请求轻量的业务。
故障自动规避能力可用：配合 max_fails 和 fail_timeout 参数（如 server 192.168.1.101 max_fails=3 fail_timeout=30s），能临时剔除不可用节点，不影响整体轮询节奏。
轮询策略的主要局限
完全忽略服务器实际性能差异：三台机器若配置不同（比如一台 8C16G，另两台 2C4G），轮询仍会平均派发请求，导致弱机迅速过载、强机资源闲置。
不感知后端实时负载：即使某台服务器当前连接数已达 2000，另一台才 200，轮询仍按固定顺序继续分发，无法动态倾斜。
无法保证会话粘性：用户刷新页面或重发请求，可能落到不同后端，对依赖本地 session 的老式 Web 应用（如未共享 session 存储的 PHP 站点）会造成登录态丢失或数据错乱。
对响应时间敏感型业务不友好：若某台后端因磁盘慢或 GC 暂停导致延迟飙升，轮询不会绕过它，后续请求仍会被持续打过去，影响整体 P95 延迟。
适合采用轮询策略的业务场景
静态资源服务集群：如图片、CSS、JS 文件托管，请求无状态、处理快、各节点性能接近，轮询既能均摊流量，又避免引入哈希或连接池等复杂逻辑。
无状态微服务网关下游：后端是基于 token 鉴权、session 存 Redis 的现代 API 服务，每次请求独立可重入，轮询提供最简健壮的分发路径。
灰度发布初期或测试环境：多版本并行时，仅需增减 upstream 中 server 行，就能快速调整流量比例（配合权重可进阶），轮询本身便于观察各实例基础承载力。
低 QPS、低复杂度内部系统：如企业内部的 CMDB 查询接口、监控告警推送服务，日均请求几千次，机器配置统一，没必要为均衡过度设计。
什么时候该考虑换其他策略
后端服务器 CPU/内存/IO 明显不均：例如混合部署物理机与容器，或新旧机型混用，应改用加权轮询，按实际能力分配流量。
用户需要“一次登录，全程不掉线”：比如传统 JSP 或 ASP.NET 应用，session 写在本地内存，必须用 ip_hash 或 hash $cookie_jsessionid 实现会话保持。
接口响应时间波动大且影响用户体验：如涉及外部 HTTP 调用或数据库慢查询的服务，建议切换至 least_conn，优先将新请求导向连接更少、大概率更空闲的节点。
需支持细粒度路由控制：比如按 URL 路径、请求头或设备类型分流，这时轮询已不是重点，应结合 split_clients 或 Lua 脚本做前置决策。
