直接用 hash $request_uri consistent 是最有效的方式，确保相同 url 请求始终落到同一后端，提升缓存命中率；必须用 $request_uri 因其含完整路径与查询参数，比 $uri、$remote_addr 更精确稳定；配置须严格遵循原生语法，禁用 weight 等不兼容指令。
直接用 hash $request_uri consistent 是最有效的方式。它让相同 URL 请求始终落到同一台后端，使每台机器只缓存自己负责的资源，避免重复加载和跨节点未命中。
为什么必须用 $request_uri 做哈希键
静态资源（JS、CSS、图片、字体等）的 URL 路径+查询参数具有强稳定性与唯一性。用 $request_uri 作为哈希输入，能保证：
- 同一资源（如 /static/logo.png?v=2.1.0）永远映射到固定后端，本地缓存可长期复用
- 不依赖客户端 IP（$remote_addr），规避 NAT、CDN 回源导致的哈希漂移
- 比 $uri 或 $host 更精确——包含完整查询参数，防止带版本号、环境标识的资源被错误分散
Nginx 官方 hash + consistent 参数配置要点
无需第三方模块，Nginx 1.7.2+ 原生支持，但必须严格遵循语法：
- 写法只能是：hash $request_uri consistent;（注意空格和分号）
- 禁用 weight、backup、max_fails 等指令——它们在 hash 模式下无效且可能触发配置校验失败
- server 行只写地址和端口，例如：server 10.0.1.10:8080;
- 不推荐用 url_hash（非官方模块）、ip_hash（不适合静态资源）或轮询（命中率骤降）
应对热点 URI 和节点扩容的实际策略
百万级集群中，纯哈希易出现局部倾斜或扩缩容抖动，需叠加两层控制：
- 对高频 URI（如商品页 /item/123456）做路径归一化：用 map 提取前缀 /item/* → /item/，再哈希，把同类请求打散到更多节点
- 节点扩容时，启用 consistent 参数后，仅影响新增节点顺时针邻近的一小段 URI 区间，其余 90%+ 请求不受干扰
- 配合 proxy_cache_valid 和 open_file_cache，让 Nginx 进程级缓存复用更充分，减少上游压力
