轮询算法能改善集群服务器进程负载均衡性，但仅在无状态、响应时间相近且配置健康检查、连接复用等机制时有效；否则可能因进程异构或状态耦合导致实际负载失衡。
轮询算法本身不改变单台服务器的处理能力，也不直接降低某台机器的 CPU 或内存占用，但它能显著改善集群中各服务器进程负载的分布均衡性——前提是后端服务无状态、响应时间相近、且配置得当。
轮询如何影响进程负载分布
轮询按请求到达顺序线性分发，比如三台后端（A/B/C），请求流就是 A→B→C→A→B→C……这种固定节奏让每台服务器接收请求的频次一致。在理想条件下（服务耗时稳定、无长连接、无会话依赖），各服务器上运行的应用进程会趋于均匀承接流量，从而避免某进程因突发请求堆积而持续高 CPU 占用，其他进程却空转。
- 对短平快请求（如 API 查询、静态资源）效果明显：进程负载曲线平滑，峰值差异小
- 对响应时间波动大的服务，可能造成“表面均衡、实际失衡”：比如 A 进程处理一个慢请求耗时 2s，B 进程同时处理两个快请求各 0.1s，轮询仍继续给 A 分发下一个请求，导致 A 进程积压
- 不感知进程级指标（如 worker 进程数、排队请求数、GC 频率），仅按 server 列表顺序调度
真正决定进程负载的关键配置项
裸轮询容易让进程负载“看起来平均，实际不稳”。生产环境必须叠加以下机制，才能让轮询真正支撑起稳定的进程负载：
- 健康检查（max_fails / fail_timeout）：及时摘除异常进程所在的服务器，防止请求持续打到已卡顿的进程上
- 连接复用（keepalive）：减少上游频繁建连带来的 worker 进程开销，尤其对高频小请求，能降低进程上下文切换压力
- 真实 IP 透传（X-Real-IP）：确保后端应用日志和限流逻辑基于客户端维度生效，避免所有请求被识别为 Nginx 内网 IP 而绕过控制，间接影响进程行为
- proxy_buffering off（必要时）：对大文件上传或流式响应，关闭缓冲可减轻 Nginx worker 进程内存压力，避免阻塞型请求拖累整个进程队列
什么时候轮询会让进程负载更糟
当后端进程存在明显异构性或状态耦合时，轮询反而加剧负载不均：
- 新旧机器混用：老服务器上进程处理同样请求耗时翻倍，但轮询仍等量分发 → 该进程 CPU 长期超 90%
- 有会话状态的服务（如 session 存内存）：用户每次请求跳到不同进程，触发重复登录、缓存重建等操作 → 某些进程反复做初始化，负载虚高
- 存在长连接或后台任务：轮询不看当前活跃连接数，可能把第 100 个 WebSocket 连接也分给已承载 99 个连接的进程 → 该进程句柄耗尽、响应延迟飙升
验证进程负载是否真被轮询优化
不能只看 Nginx 日志里 IP 出现次数是否平均，要深入到后端进程层面：
- 在每台后端服务器上，用 top -H -p $(pgrep -f "your_app_process") 观察各线程（即 worker 进程）的 CPU 和内存占用趋势
- 对比同一时间段内，各服务器上应用进程的平均响应时间（如通过 Prometheus + application metrics）
- 发起连续请求并抓包：for i in {1..12}; do curl -sI http://nginx/ | grep "Server:"; done，确认返回头中的 server 标识严格轮转，再结合后端 access.log 时间戳交叉比对
