hash $request_uri可确保相同URL请求始终路由至同一后端服务器，提升本地缓存复用率与命中率；需配合consistent参数启用一致性哈希，并避免混用weight等不兼容指令。
直接用 hash $request_uri 可以让相同 URL 的请求始终落到同一台后端服务器，从而提升本地缓存复用率。这不是“锦上添花”，而是静态资源集群中提升命中率最有效的手段之一。
为什么 hash $request_uri 能提高缓存命中率
静态资源（如图片、JS、CSS）通常被部署在多台无状态后端节点上，如果采用轮询或随机分发，同一资源可能被不同节点各自缓存一次，而用户后续请求又可能打到其他节点——导致缓存未命中。启用 hash $request_uri 后：
- 每个完整 URI（含路径和查询参数）经哈希后映射到固定后端，保证“同 URL → 同机器”
- 后端节点只需缓存自己负责的那部分资源，避免重复加载和存储浪费
- 实测案例中，商品详情页集群缓存命中率从 65% 提升至 92%
基础配置写法与关键细节
在 upstream 块中启用 URI 哈希，注意以下几点：
- 必须使用
hash $request_uri，不是url_hash（那是第三方模块名，Nginx 官方原生不支持该指令） - 推荐加上
consistent参数，实现一致性哈希，增删节点时减少缓存失效范围：hash $request_uri consistent; - 不能混用
weight、backup、max_fails等参数——Nginx 哈希调度模式下这些参数会被忽略或报错 - 示例配置：
hash $request_uri consistent;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
配合缓存策略效果更佳
单靠哈希只是第一步，还需确保后端真正做了有效缓存：
- 后端服务（如 Nginx 或应用层）应基于
Cache-Control和ETag正确响应缓存头 - 若用 Nginx 自身做代理缓存，建议开启
proxy_cache_use_stale updating，缓解缓存更新时的穿透压力 - 监控
$upstream_cache_status日志字段，确认 HIT 比例真实上升（而非仅因哈希“看起来更稳定”）
什么情况下慎用或需调整
URI 哈希不是万能解，要注意实际业务特征：
- URL 中带高频变动参数（如
?t=1712345678、&utm_source=xxx）会导致哈希散列分散，建议用$uri替代$request_uri，或通过map指令标准化参数 - 资源访问极不均衡（如某张图被千万次请求），单台机器可能成为热点，可结合
least_conn或动态扩容应对 - 若后端节点能力差异大，哈希无法自动调节负载，此时需评估是否引入二级负载（如前置 CDN 或 LVS）分担压力
