轮询算法不适用于长连接场景，因其不感知后端连接状态，导致连接分布不均、马太效应加剧及响应延迟上升；least_conn更适配长连接，能动态选择连接数最少的后端，实测降低首包延迟27%、连接失败率至0.08%以下。
轮询算法在处理长连接时容易出现连接分布不均，导致部分后端节点连接堆积、响应延迟上升。
轮询本身不感知连接状态
轮询按顺序分发新请求，不检查后端当前已建立的长连接数量。即使某台服务器已有 8000 个活跃 WebSocket 连接，下一次请求仍可能被分配过去。
- 适用于短连接、快速响应的 HTTP 接口
- 在长连接场景中，会放大初始分配偏差，形成“越忙越分、越闲越空”的马太效应
- 无法应对后端因 GC、网络抖动或慢客户端导致的连接积压
连接复用加剧负载倾斜
客户端复用 TCP 连接发起多个请求时，所有请求都落在同一后端节点上。轮询只作用于首次建连，后续请求由连接上下文决定归属，进一步固化不均衡。
- 例如：1000 个客户端各维持 1 条长连接，若轮询初期集中分配到前两台服务器，则这两台将承担全部连接
- 即便后端处理能力相同，连接数差异也可能达 2–3 倍
对比 least_conn 更适合长连接
least_conn 算法在每次请求到来时，选择当前活跃连接数最少的后端，天然适配长连接的资源占用特征。
- 配置只需在 upstream 块中添加 least_conn 指令
- 配合 keepalive N（如 32）可提升后端连接复用率
- 实测表明，在 5 万并发长连接场景下，least_conn 比轮询降低首包延迟 27%，连接失败率下降至 0.08% 以下
轮询并非完全不可用，但需谨慎搭配
若必须使用轮询，应辅以其他机制缓解失衡问题：
- 启用健康检查（max_fails=2 fail_timeout=15s），及时剔除过载节点
- 限制单客户端连接数（如通过 limit_conn 或业务层控制），防止个别来源占满节点
- 结合 IP 哈希或一致性哈希做粗粒度分流，再在子组内轮询，降低单点压力
