轮询调度天然适配无状态业务，因其不依赖后端状态、不干预请求逻辑，仅按顺序分发请求，使流量均匀摊平到各节点；无状态服务无本地缓存、不保存会话、请求可独立处理，与轮询的顺序分发机制完全匹配，只要后端规格一致、响应时间接近，即可实现CPU和连接数基本均衡。
轮询调度天然适配无状态业务，它不依赖后端状态、不干预请求逻辑，只按顺序分发，让流量自然摊平到各节点上。
为什么无状态业务和轮询最搭
无状态服务本身没有本地缓存、不保存会话、不依赖前序请求上下文，每个请求都能独立处理。轮询的“顺序分发”机制正好匹配这种特性——不需要识别用户、不关心上次在哪台机器执行、也不需要同步状态。只要后端实例规格一致、响应时间接近，轮询就能让每台机器的 CPU 和连接数基本拉齐。
- 静态资源服务（如图片、JS/CSS）、RESTful API 网关、日志上报接口等，都是典型适用场景
- 微服务中鉴权、限流、路由等无状态中间层，用轮询接入既轻量又稳定
- 新集群上线或快速扩容时，“加机器→加 upstream → reload”三步即可生效，零额外配置
必须补上的基础配置项
轮询默认开启，但裸用风险高。生产环境至少要加三项保障：
-
健康检查：每个 server 行加上
max_fails=3 fail_timeout=30s，连续失败三次就暂停转发，避免把请求打到已宕机的节点 -
真实 IP 透传：在 location 块里写
proxy_set_header X-Real-IP $remote_addr，确保后端日志、限流、审计能识别真实客户端 -
连接复用：启用
keepalive 32并配合proxy_http_version 1.1和proxy_set_header Connection ''，减少高频短连接的 TCP 握手开销
什么时候轮询开始不靠谱
一旦业务或后端出现以下情况，轮询的“次数公平”就会失灵：
- 后端混用不同规格机器（比如 2 核和 8 核共存），CPU 利用率可能差出一倍以上，此时应改用加权轮询
- 服务实际有隐式状态（例如本地缓存未清理、临时文件未清理、内存中存了用户偏好），会导致请求跳转后结果异常
- 存在长耗时操作（如大文件上传、报表导出），轮询不看当前连接负载，容易在某台机器上堆积请求
怎么确认轮询真在工作
别只看配置有没有写对，得验证流量是否真的在循环走：
- 用命令快速发起多个请求：
for i in {1..6}; do curl -s http://your-nginx/api/health | grep host; done，观察返回的 host 是否按顺序交替 - 在后端响应头里加
X-Backend-Id，通过浏览器开发者工具或 Nginx access 日志直接追踪路由路径 - 查 Nginx stub_status 或 Prometheus 监控，对比各 upstream 节点的 request count，偏差超过 15% 就值得排查
