轮询仅负责将用户请求均匀分发至各边缘节点，不参与缓存决策；缓存行为由边缘节点根据cache-control等响应头独立判断，二者职责分离。
轮询调度本身不参与 CDN 缓存决策，它只管把用户请求分发给哪台后端节点；而 CDN 是否缓存、缓存多久、是否回源，完全由响应头中的 Cache-Control 决定。两者分工明确：轮询是“派活的人”，缓存是“干活的人”自己判断要不要留副本。
轮询在 CDN 架构里负责什么
在典型 Nginx + CDN 边缘节点架构中（比如 1 台 LB Nginx + 3 台边缘 Nginx 节点），轮询仅作用于负载均衡器这一层：
- 用户请求先到达 LB Nginx
- LB 按 upstream 中 server 的顺序，逐个分配请求到 Edge1/Edge2/Edge3
- 每台边缘节点收到请求后，独立判断：本地有缓存且未过期 → 直接返回；否则回源（如 SRS 源站）拉取并缓存
也就是说，轮询不决定“缓不缓存”，只决定“让谁来处理这个请求”。缓存行为发生在边缘节点内部，与轮询逻辑隔离。
为什么轮询均匀 ≠ 缓存命中率均匀
即使轮询把请求 1:1:1 分给三台边缘节点，各节点的缓存效果仍可能差异很大：
- 各节点初始缓存为空，首批请求都会回源，但后续命中率取决于访问模式（比如某节点恰好承接了大量重复流请求）
- 缓存清理策略不同（如 max_size 或 inactive 时间不一致），导致节点间缓存容量或驻留时长不等
- 某节点因网络抖动短暂失联，被 LB 摘除，剩余两台承担更多请求，自然积累更多缓存
所以观察到某台边缘节点缓存命中率高，并不说明轮询偏了，而是它“运气好”或“配置更稳”。
让轮询和缓存协同工作的关键配置
要让整体分发稳定、缓存高效，需在两个层面保持一致性：
- LB 层清干净：upstream 块里只写裸 server 地址，删掉 weight、ip_hash、hash 等干扰项，确保请求真正按序轮转
- 边缘层统策略：所有 Edge Nginx 都启用相同 cache_path 参数（如 levels=1:2 keys_zone=cache_hls:10m max_size=10g）、统一 proxy_cache_valid 规则（如 200 302 1h）、一致的 Cache-Control 输出（如 HLS 片设 max-age=30s）
- 验证靠日志：在 LB 和各 Edge 上开启 $upstream_addr 和 $sent_http_cache_control 日志字段，能清楚看到“谁收到了请求”+“它返回了什么缓存指令”
实际部署中容易踩的坑
常见问题往往不是轮询错了，而是缓存和分发没对齐：
- 边缘节点返回 Cache-Control: no-cache，但 LB 还在轮询——结果所有请求都回源，看似“轮询失效”，其实是缓存策略关了
- 某台 Edge 配了 proxy_cache_use_stale updating，其他没配，导致它在更新缓存时仍可返回旧内容，响应更快、更容易被轮询选中，形成隐性权重
- LB 启用了 keepalive 连接复用，而边缘节点设置了不同的 proxy_http_version 或 Connection 头，造成连接复用不均，间接影响请求分布统计
不复杂但容易忽略。
