轮询策略仅实现请求数均摊而非负载均摊，适合性能均一、响应稳定的场景；遇响应时延差异、资源瓶颈或长耗时操作时易失衡，需结合健康检查、slow_start、queue等机制优化。
轮询策略在高流量下仍能保持基本的请求分发均匀性，但它的“均衡”仅体现在请求次数层面，不反映真实负载压力。它适合后端服务器性能接近、处理耗时稳定的场景；一旦存在响应时间差异或资源瓶颈，实际负载就容易失衡。
轮询的均衡性本质是“请求数均摊”，不是“负载均摊”
轮询按顺序把每个新请求发给下一台服务器，比如三台节点 A/B/C，请求流就是 A→B→C→A→B→C……这种机制不采集 CPU、内存、连接数或响应时间等指标。即使某台机器响应慢了 300ms，轮询照样继续派发，可能造成请求堆积、超时增多、队列拉长。
- 高并发时，慢节点会积压更多等待连接，而快节点可能已空闲
- 日志统计显示请求数接近 1:1:1，但监控里 CPU 和延迟曲线可能明显分化
- 对短平快接口（如状态检查、轻量查询）影响小；对长耗时操作（如文件上传、报表生成）风险上升
影响高流量下表现的关键配置项
轮询本身无参数，但搭配健康检查和容错机制，能缓解部分失衡问题：
- max_fails/fail_timeout：及时隔离异常节点，避免持续转发失败请求
- slow_start：新上线服务器可缓慢提升流量，防止瞬间压垮
- queue 指令（1.25.0+）：为 upstream 设置请求队列，缓冲突发流量，降低直接打满后端的风险
- 配合 keepalive 复用连接，减少握手开销，间接提升吞吐稳定性
什么情况下轮询会明显失衡？
以下情况会让轮询的“表面均衡”快速失效：
- 后端节点硬件或部署环境不一致（例如混合使用 4C8G 和 16C64G 实例）
- 服务中存在大量长连接或阻塞型 I/O（如数据库慢查询未优化）
- 某些路径触发高频缓存穿透或冷启动（如首次加载大模型权重）
- 客户端请求体差异极大（KB 级表单 vs MB 级上传），导致处理时间方差扩大
替代或增强方案建议
若实测发现轮询在高峰时段引发节点负载抖动或错误率攀升，可考虑：
- 改用 least_conn：更适合长连接或响应时间波动大的服务
- 启用 ip_hash + session 共享：保障会话连续性，同时规避单 IP 风控误伤
- 引入外部动态权重（如通过 Lua 脚本读取 Prometheus 指标调整 weight）
- 前置一层服务网格（如 Envoy）做更细粒度的负载感知路由
