Nginx 中轮询算法对静态内容分发集群的应用

轮询适合静态内容分发，因其无状态、响应快、服务器同构，能均匀分发请求且配置简单；配合健康检查可自动容错，但遇性能差异大、需会话保持或长连接场景时应换用加权轮询、ip_hash或least_conn。

轮询算法是 Nginx 分发静态内容最常用、最稳妥的选择，尤其适合配置一致、无状态的静态资源集群。

为什么轮询适合静态内容分发

静态资源（如图片、CSS、JS、字体文件）本身不依赖会话、无需服务端状态保持，且响应快、计算轻。轮询天然满足这些特点：

1. 请求处理无状态，每台服务器独立返回文件，不需共享 session 或缓存状态
2. 响应时间稳定，极少出现长尾延迟，轮询不会因某台服务器暂时卡顿而明显失衡
3. 服务器硬件和部署环境通常高度同构（比如统一镜像、相同规格 VM），负载能力接近，轮询能实现近似均匀的流量分布
4. 配置零成本：无需设置 weight、ip_hash 或额外模块，开箱即用

典型配置与实际效果

一个三节点静态资源集群可这样配置：

upstream static_servers {server 10.0.1.10:80;server 10.0.1.11:80;server 10.0.1.12:80;}server {location /static/ {proxy_pass http://static_servers;}}

在真实压测中，三台服务器的请求占比通常落在 33%±2% 范围内，偏差主要来自 TCP 连接复用、Nginx worker 进程调度微抖动等正常因素，不影响整体均衡性。

配合健康检查提升稳定性

静态服务虽简单，但单点故障仍需自动规避。轮询本身支持基础容错：

1. 通过 max_fails=3 fail_timeout=30s 可让 Nginx 在连续失败 3 次后，30 秒内不再向该节点转发请求
2. 故障恢复后，Nginx 自动重新纳入轮询队列，无需人工干预
3. 建议搭配 proxy_next_upstream error timeout http_500 http_502，确保后端返回错误时自动重试其他节点

什么情况下要换掉轮询

轮询不是万能的，遇到以下情况应主动调整：

1. 集群中混入不同规格机器（例如部分节点 SSD+16G 内存，部分为 HDD+4G），导致响应延迟差异大 → 改用加权轮询
2. 需要客户端始终从同一节点获取资源（如 CDN 边缘缓存一致性要求强）→ 考虑 ip_hash 或一致性哈希（需第三方模块）
3. 静态资源带大量 Range 请求或大文件下载，连接持续时间长 → 可评估 least_conn 算法，避免单节点堆积过多长连接