轮询算法不提升缓存命中率，反而在本地缓存场景下导致命中率趋近于0；其价值在于流量分发公平性，真正影响命中率的是轮询与缓存层级设计的兼容性。
轮询算法本身不提升缓存命中率，反而可能显著拉低它——尤其在依赖本地 JVM 缓存或未做 key 一致性路由的场景下。它的核心价值是流量分发的公平性与稳定性，而非缓存协同。真正影响命中率的，是轮询是否与缓存层级的设计逻辑相容。
轮询为何常导致缓存命中率暴跌
当应用节点各自维护独立本地缓存（如 Caffeine、Guava Cache），而 Nginx 仅按顺序分发请求时，同一资源（如 /api/user/123）会反复打到不同机器上：
- 第一次请求落到 node-A → 查询 DB 并写入 A 的本地缓存
- 第二次请求轮到 node-B → B 缓存为空 → 再次查 DB，重复加载
- 结果：本地缓存始终“冷”，命中率趋近于 0，数据库压力倍增
这种现象在商品详情、用户资料等读多写少接口中尤为典型，不是缓存没配好，而是轮询和缓存部署方式根本冲突。
什么时候轮询能与缓存共存
轮询并非完全不能用，关键看缓存层级的位置和类型：
- 后端是统一分布式缓存（如 Redis Cluster）：所有节点共享同一份数据，本地缓存只是可选加速层，轮询不会破坏一致性
- 接入层已做 key 哈希分流（如 URI Hash / Cookie Hash）：轮询退居为兜底或健康检查后的备用策略，主流量由哈希保障粘性
- 缓存命中逻辑下沉至网关或代理层（如 Envoy + Redis Proxy）：Nginx 轮询只负责导流到缓存代理，不再直连应用节点
若必须用轮询，如何缓解命中率损失
不能改架构时，可通过配置补位降低伤害：
- 启用 proxy_cache_lock on：防止多个节点同时回源加载同一资源，减少 DB 冗余压力
- 设置 fastcgi_cache_min_uses 2 或 3：避免探针、爬虫、带随机参数的请求污染缓存池
- 缩短 proxy_cache_valid 中动态接口的 TTL（如 15s），配合 proxy_cache_use_stale updating，让过期请求后台刷新，前台仍返回旧值
- 在应用层强制预热高频 key（如启动时加载 TOP1000 商品 ID），弥补轮询带来的冷启动缺口
更优替代方案：哈希类算法直接对齐缓存逻辑
比起“救火式”调参，换算法往往更治本：
- ip_hash：适合内网固定 IP 场景，但存在单点集中风险
- hash $request_uri consistent：Nginx Plus 或开源版搭配第三方模块，实现一致性哈希，增减节点时缓存迁移最小化
- hash $arg_id：针对带明确业务 ID 的接口（如 ?id=1001），精准绑定节点
这些方式让请求天然落在同一节点，本地缓存才能真正复用，命中率从根源上回升。
