nginx原生支持hash $key consistent（1.7.2+），通过ketama哈希环实现节点增减时仅少量请求重映射，大幅降低缓存失效；需在upstream中配置稳定变量如$remote_addr或$request_uri，并配合proxy_cache_lock与统一缓存key使用。
直接用 Nginx 做一致性哈希，核心目标是：后端加机器或下机器时，尽量少让缓存失效。它不是靠“运气”固定请求，而是通过哈希环机制，让绝大多数请求仍打到原来的后端，只影响邻近的一小部分。
官方 hash + consistent 是最简方案
Nginx 1.7.2 起原生支持 hash $key consistent;，无需编译第三方模块。它基于 ketama 算法思想，内部构建虚拟节点环，节点变动时重映射比例远低于普通取模哈希。
- 必须写在 upstream 块内，且 key 变量要稳定——推荐 $remote_addr（会话亲和）或 $request_uri（缓存复用）
- 若需忽略 URL 参数，改用 $uri；若参数关键但格式混乱，先用 map 指令标准化再哈希
- 不加 consistent 参数就是普通静态哈希，节点一变，几乎全部重分配
第三方模块提供更严格的一致性保障
当业务对缓存命中率极其敏感（比如 CDN 或高并发商品详情页），可选用 ngx_http_consistent_hash 模块。它实现更贴近经典一致性哈希定义，支持更多变量、更细粒度控制。
- 需源码编译安装：./configure --add-module=/path/to/ngx_http_consistent_hash
- 配置简洁：consistent_hash $request_uri; 即可启用，支持 $args、$host、$http_x_forwarded_for 等
- 注意：该模块不支持 weight 权重，所有 server 默认等权；如需权重，得换用其他兼容模块或自行改造
配合 proxy_cache 才真正减少回源
一致性哈希只是把请求“钉”到某台后端，但能否命中缓存，还取决于后端自身是否缓存、缓存规则是否统一。
- 各后端服务的缓存 Key 必须一致——例如都 strip 掉 utm_ 类参数，否则同一 URI 在 A 机缓存的是带参版本，在 B 机缓存的是无参版本，内容不一致
- Nginx 的 proxy_cache 是 per-worker 级别，不跨进程共享；只要 consistent_hash 保证相同请求总落到同一台后端，且该后端有本地 cache 或共享 Redis，效果就明显
- 务必开启 proxy_cache_lock on;，防止缓存未命中时多个相同请求同时穿透到上游，引发瞬时回源高峰
Kubernetes Ingress 场景下的配置方式
在使用 Nginx Ingress Controller 的集群中，无需改动 Nginx 配置文件，直接通过注解声明即可启用一致性哈希。
- Ingress 注解写法：nginx.ingress.kubernetes.io/upstream-hash-by: "$request_uri"
- 适用于 v1.23+ 版本的 Ingress Controller；旧版本可能需启用 alpha 功能或换用 custom annotations
- 注意：该注解作用于 Service 后端 Pod，不是 Ingress 自身的 upstream；确保后端 Pod 数量稳定，否则仍会触发部分重分布
