轮询算法不提升并发量，仅均匀分发请求；真正决定并发能力的是Nginx的epoll事件模型、worker进程数与连接数配置；需配合健康检查、加权轮询及会话粘性策略才能高效运行。
轮询算法本身不提升并发量，它只负责把已到达的请求均匀分发到后端服务器。真正影响并发处理能力的是 Nginx 自身的事件驱动架构和系统级配置，轮询只是在高并发基础上做流量分配的“公平器”。要让它调度更合理、不拖慢整体吞吐，得从几个关键点入手。
轮询必须运行在高并发基础之上
单靠轮询无法应对高并发。Nginx 能扛住数万连接，靠的是 epoll（Linux）事件模型、多 worker 进程 + 异步非阻塞 I/O。如果没配好这些，轮询再“均匀”，请求也会卡在代理层：
- use epoll; 显式启用高效事件机制（Linux 环境）
- worker_processes 设为 CPU 物理核心数，避免进程争抢
- worker_connections 需结合系统 ulimit -n 调整，确保单 worker 能处理足够连接
轮询需搭配健康检查才不误发请求
默认轮询不判断后端是否存活，宕机的机器照样收请求，失败率直接上升。必须让 Nginx 主动探测并自动摘除异常节点：
- 每个 server 行加上 max_fails=3 fail_timeout=30s，连续失败3次就剔除30秒
- 如需 HTTP 层探测（比如检查返回码或响应内容），启用 ngx_http_upstream_health_check_module 并配置 health_check
- 避免仅靠 passive 检查，建议配合主动探测提升恢复及时性
按后端实际能力调整轮询方式
纯轮询假设所有服务器性能一致，现实中往往不是这样。若某台机器 CPU 更强、内存更大，却和弱机分到一样多请求，整体效率反而下降：
- 用 weight 参数做加权轮询，例如 server 192.168.1.10 weight=5;
- 权重值可参考 CPU 核心数、内存容量或历史 QPS 数据设定，不建议凭空猜测
- 若后端支持动态扩缩容，建议接入 Prometheus + OpenResty 脚本，实现权重自动调节
轮询适合无状态服务，慎用于有会话依赖场景
轮询天然无状态，同一用户多次请求可能落到不同后端，导致 session 丢失或数据不一致：
- API 网关、静态资源、读多写少的查询服务，轮询很合适
- 登录态强依赖、购物车等场景，应改用 ip_hash 或引入外部 session 存储（如 Redis）
- 若必须保留轮询又需会话粘性，可用 cookie hash（sticky cookie）替代 ip_hash，更适应 NAT 环境
