轮询算法本身不提升静态文件分发效率，关键在于按实测带宽设权、热度感知路由、dns ttl与健康检查对齐，并绑定可观测指标持续优化。
轮询算法本身不直接提升静态文件分发效率，它只是按顺序把请求“甩”给后端服务器。真正让静态资源快起来的，是轮询怎么配、跟谁配、什么时候调——核心在匹配资源特性与节点能力。
加权轮询必须按带宽设权，不是看CPU或内存
静态资源服务几乎不压CPU、不占内存，但吃带宽、要并发连接。如果三台服务器里有两台是1Gbps、一台只有100Mbps，纯轮询会让约1/3请求落到慢节点上，拖垮TTFB和下载完成率。
- 权重应严格按实测带宽比例设置，比如 10:10:1（对应1Gbps : 1Gbps : 100Mbps）
- 禁用以CPU使用率或内存占用为依据的自动权重——这些指标对静态服务无意义
- 每24小时校准一次权重，依据Nginx的
$upstream_response_timeP95延迟反推节点实际服务能力
热门资源走固定路由，冷资源才进轮询池
前端静态资源缓存强（max-age=1年），真实回源请求集中在发布窗口、缓存失效期或小众图标等场景。轮询若不感知热度，容易一边空转、一边积压。
- 在负载均衡器侧接入轻量热度统计（如Redis HyperLogLog，按URI统计1小时UV）
- UV > 1000 的资源，强制固定路由到指定高性能节点，跳过轮询
- UV
DNS TTL 与轮询周期必须对齐
浏览器对同一域名并发请求上限6–8个，且依赖DNS缓存。若Nginx刚把请求切到新节点，而客户端还在用旧IP，就会打到已下线机器，返回502或超时。
- DNS TTL设为60秒，与Nginx upstream健康检查间隔保持同量级
- HTML中用子域名分流资源（如 static1.example.com / static2.example.com），每个子域名独立配置轮询池
- 禁用
dns-prefetch，防止浏览器预解析过期IP
轮询决策必须绑定可观测指标
启用轮询只是开始，没日志、没热力图，等于闭眼开车。
- 记录每次调度日志：request_id、server_ip、weight、response_time、status_code
- 绘制“节点响应时间热力图”，识别长期偏高延迟节点（可能是磁盘老化或网卡错包）
- 把轮询动作和CDN日志、边缘缓存命中率联动分析，定位真实瓶颈在回源还是边缘
不复杂但容易忽略
