轮询调度是Nginx最基础负载均衡方式，需按业务场景优化：静态资源用默认轮询+健康检查；短连接API宜配least_conn；混合部署应合理设置权重。
轮询调度是 Nginx 最基础也最常用的负载均衡方式，它不依赖额外模块，开箱即用，但实际应用中不能只写几行 server 就完事——不同业务逻辑对稳定性、一致性、响应效率的要求差异很大，配置必须跟着业务走。
Web 静态资源服务：默认轮询 + 健康检查
静态资源（如图片、JS、CSS）通常由多台性能相近的 CDN 边缘节点或对象存储网关提供，请求无状态、响应快。这时默认轮询足够，但需叠加基础容错：
- 每台后端加 max_fails=3 fail_timeout=30s，Nginx 会自动屏蔽连续失败的节点
- 避免使用 backup 节点做兜底，除非有明确的灾备切换策略；否则容易在流量突增时引发雪崩
- 日志里观察各节点 access 日志请求数，偏差超过 ±15% 就要排查网络或后端响应延迟是否异常
短连接 API 接口：轮询 + least_conn 优化
RESTful API 多为短连接、高并发、处理时间波动大（比如有的接口查缓存快，有的要查数据库慢），纯轮询可能让慢节点积压更多请求。这时应在 upstream 中启用 least_conn：
- 配置写法：upstream api_backend { least_conn; server 10.0.1.10:8000; server 10.0.1.11:8000; }
- 它不是按顺序发请求，而是每次选当前活跃连接数最少的后端，更适合短连接场景
- 注意：不要和 ip_hash 同时使用，二者冲突；也不建议在长连接（如 WebSocket）中盲目启用
混合部署环境：轮询 + 权重微调
生产环境中常存在新旧服务器混用（比如一台 16 核新机器配两台 8 核老机器），完全不用权重会导致新机器空转、老机器过载。此时可给轮询“加一点智能”：
- 权重不追求精确百分比，按 CPU 核心数或内存比例粗略设定，例如新机器 weight=4，老机器各 weight=2
- 权重值建议控制在 1–10 区间，避免过大数值导致小权重节点长期收不到请求
- 上线后观察 $upstream_addr 日志字段，确认实际分发比例与预期基本一致（误差
需要会话保持但又不想用 ip_hash 的场景
有些业务（如登录态较短的管理后台）希望用户尽量不跳机，但又担心 ip_hash 在 NAT 环境下失效或扩容时会话大量丢失。这时可用轮询配合外部会话治理：
- 关闭 ip_hash，保持纯轮询结构
- 后端统一接入 Redis 存储 session，并设置合理过期时间（如 30 分钟）
- Nginx 层通过 proxy_cookie_path 或 proxy_hide_header Set-Cookie 配合后端透传 cookie，避免本地 session 冲突
