Nginx中consistent_hash指令可显著减少节点变更时的缓存错配，提升命中率至90%以上；需先编译安装第三方模块，再在upstream块首行配置consistent_hash $request_uri等稳定变量，且不支持与weight等参数共用。
直接在 upstream 块中使用 consistent_hash 指令，配合语义稳定、区分度高的哈希变量（如 $request_uri 或 $remote_addr），就能显著减少节点增减时的缓存错配，把缓存命中率稳定在 90% 以上。
确认模块已启用
Nginx 官方主线版本默认不包含 consistent_hash，但 Tengine 和部分编译增强版已内置。若用原生 Nginx，需手动编译第三方模块：
- 下载并解压
ngx_http_consistent_hash模块源码 - 重新编译 Nginx：
./configure --add-module=/path/to/ngx_http_consistent_hash [其他选项] - 执行
make && make install，再验证：nginx -V 2>&1 | grep consistent
选择合适的一致性哈希输入变量
哈希变量决定请求“归属”的稳定性。选错会导致同一业务请求分散到多个节点，削弱缓存效果：
-
$request_uri：适合静态资源或查询类接口（如
/api/items?id=123），URI 稳定且天然区分请求内容 -
$remote_addr：适合需按客户端 IP 保持会话的场景，但注意代理环境下需用
X-Real-IP替代 -
$host$args：比单用
$args更全面，避免子域名或参数组合重复导致哈希碰撞 - 避免用
$time_iso8601、$request_time等动态变量——每次请求值都不同，哈希完全失效
配置 upstream 并验证行为
写法简洁，但必须放在 upstream 块首行（在 server 行之前）：
upstream cache_backend {
consistent_hash $request_uri;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
关键点：
- 不支持
weight、max_fails等参数与consistent_hash共存（Tengine 除外） - 节点上下线时，仅约
1/N的 key 会重映射（N 为节点数），远优于普通取模哈希 - 用
curl -I http://your-domain/some-path多次测试相同 URI，观察X-Upstream-Addr（需自定义日志或后端回传）是否始终落在同一台机器
搭配缓存策略协同生效
一致性哈希只是路由前提，真正提升命中率还需后端配合：
- 后端服务对相同 URI 的响应应尽量缓存（如设置
Cache-Control: public, max-age=3600） - 禁用可能导致响应差异的中间件（如随机打标、时间戳注入）
- 若用 Redis 做二级缓存，建议按
uri或uri+query_md5构建 key，与 Nginx 哈希逻辑对齐 - 监控指标：重点关注各节点的
cache_hit_ratio标准差，越小说明负载与缓存分布越均衡
