轮询不适合大规模集群，需配合weight、健康检查、重试等配置加固，并结合least_conn、ip_hash等策略及可观测性支撑才能有效使用。
轮询本身不直接支持大规模集群，它是一种轻量、静态的分发机制，适合中小规模、后端能力均一的场景。要在大规模集群中有效使用轮询，必须配合多项增强配置和外部协同策略，否则容易出现负载倾斜、故障扩散或长尾延迟放大等问题。
轮询在大规模集群中的天然局限
轮询只按顺序发请求，不感知后端实时负载、响应时长或连接数。当集群节点数超过5–8台，或存在硬件差异、部署环境不一致（如部分节点带SSD缓存、部分无）、服务响应时间波动大（如AI推理耗时30–120秒）时，纯轮询会导致：
- 强节点空转，弱节点请求堆积超时
- 某台宕机后流量仍会周期性打过去，直到max_fails触发剔除
- 无法适配扩缩容节奏，新节点上线即满载，老节点下线前仍持续收请求
让轮询在大规模集群中可用的关键加固项
不是放弃轮询，而是用配置补足它的“静态性”缺陷：
- 显式设置 weight + max_conns：对不同规格节点分级承载。例如 GPU 实例设 weight=3 max_conns=150，CPU 实例设 weight=1 max_conns=80，既体现能力差异，又防止单点雪崩
- 启用被动健康检查：每台 server 后加 max_fails=2 fail_timeout=20s，Nginx 在连续失败后自动隔离，避免反复试探已不可用节点
- 开启 proxy_next_upstream retry：当某台后端返回 502/504 或超时时，自动重试下一个节点（注意控制重试次数，避免放大延迟）
- 复用连接 + 控制缓冲：upstream 块内加 keepalive 32；location 中设 proxy_buffering off（对流式响应如音频生成更友好），并调大 proxy_buffers 和 proxy_busy_buffers_size
结合业务特征选择替代或混合策略
轮询不是唯一选项，大规模集群应按需组合：
- 长连接或响应时间差异大的服务（如 ACE-Step 音乐生成），优先用 least_conn，它看的是当前活跃连接数，比轮询更能反映真实压力
- 需保持用户上下文（如登录态、会话缓存），用 ip_hash 或 hash $request_uri consistent，减少后端状态同步开销
- 节点频繁扩缩容时，搭配 slow_start=60s，让新节点逐步承接流量，避免冷启动冲击
运维层面的必要支撑
轮询能否在大规模集群中稳定运行，最终取决于可观测性和闭环反馈：
- 通过 Nginx stub_status 或 Prometheus nginx-exporter 采集各 upstream 的 request count、response time、failed requests
- 设置告警规则：单节点 5xx 率 > 5% 或 P95 延迟突增 200%，触发人工介入或自动脚本调整 weight
- 配合 CI/CD，在扩容时自动生成含 slow_start 和合理 weight 的 upstream 配置片段，避免手工误配
