Nginx中consistent_hash用于缓解后端扩缩容时缓存大规模失效，由第三方模块ngx_http_consistent_hash提供，通过哈希环将相同key请求固定到同一后端，仅少量key迁移；需编译安装模块并配置upstream，支持$request_uri等变量，配合proxy_cache使用时需统一缓存key、启用proxy_cache_lock等。
在 Nginx 中使用 consistent_hash（一致性哈希）主要是为了解决后端节点增减时缓存大规模失效的问题，但它本身不是 Nginx 官方模块的原生指令，而是由第三方模块 ngx_http_consistent_hash 提供的功能。它通过将请求键（如 URI、参数、IP 等）映射到一个哈希环上，使相同 key 的请求尽可能固定打到同一台后端服务器，从而提升缓存命中率和系统稳定性。
为什么普通轮询或 IP 哈希会导致缓存失效？
默认的负载均衡策略（如 round_robin 或 ip_hash）在后端扩容或缩容时，会改变整体分配逻辑：
- 轮询：节点变动后，请求顺序重排，原来命中 A 缓存的请求可能落到 B，而 B 没有该缓存，触发回源和重建；
- IP 哈希：虽然客户端 IP 固定，但新增节点后哈希桶数量变化，部分 IP 映射关系改变，同样导致缓存错位；
- 一致性哈希优势：仅影响哈希环上邻近节点，理论上只有少量 key 需要迁移，大幅降低缓存雪崩风险。
如何配置 consistent_hash 模块？
需先编译安装第三方模块，再在 upstream 块中启用：
1. 编译时添加模块（以源码方式）：
2. 配置示例（按请求 URI 做一致性哈希）：
upstream backend {
consistent_hash $request_uri;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
支持的变量包括：$request_uri、$args、$remote_addr、$host 等，选择业务语义稳定、区分度高的变量更利于缓存复用。
搭配 proxy_cache 使用的关键点
一致性哈希只是把请求“固定”到某台后端，真正减少回源还需配合本地缓存策略：
- 确保各后端服务的缓存 Key 规则一致（如都忽略某些动态参数），否则同一 URI 在不同机器缓存内容可能不一致；
- Nginx 的
proxy_cache是 per-worker 进程级缓存，不同 worker 不共享，但只要 consistent_hash 把相同请求始终路由到同一台后端，且该后端自身有共享缓存（如 Redis）或足够大的本地 cache，效果就明显； - 建议开启
proxy_cache_lock，防止缓存未命中时多个相同请求同时回源； - 可结合
proxy_cache_use_stale应对后端临时不可用，进一步保障可用性。
注意事项与常见误区
该模块不支持权重（weight）、健康检查（health_check）等高级特性，实际生产中需权衡：
- 若后端节点性能差异大，无法用 weight 调节流量，需靠上游限流或应用层适配；
- 节点宕机时，模块默认会跳过故障节点继续找下一个顺时针节点，但不会自动剔除——建议配合
max_fails+fail_timeout使用； - 哈希环默认虚拟节点数为 160，可通过
consistent_hash_points 500;提高分布均匀性（需模块支持该指令）； - 不适用于需要强会话保持的场景（如登录态写入本地 session），应改用 sticky cookie 或集中式 session 存储。
