Nginx原生支持一致性哈希，只需在upstream块中配置hash $key consistent;，配合稳定业务键（如用户ID、URI）即可实现节点变更时仅约1/N请求重分布，显著提升缓存命中率与会话一致性。
直接用 hash 指令配合 consistent 参数，就能在 Nginx upstream 中启用一致性哈希策略。它不依赖客户端 IP，也不按轮询或连接数分配，而是把请求的某个稳定特征（比如 URL、Cookie、请求头）映射到哈希环上，确保相同特征的请求始终落到同一台后端——这对缓存命中、数据库分片、会话关联等场景特别关键。
明确哈希键：选对输入才能保证局部性
一致性哈希的效果高度依赖哈希键（key）的稳定性与业务语义匹配度。不能随便用随机值或易变字段。
- 推荐用业务标识：如用户 ID、订单号、设备指纹等，这些在一次业务流中不变，且天然具备数据归属含义
-
慎用请求路径：若 URL 含时间戳、随机参数或版本号（如
/api/v2/user?ts=1714501234），会导致哈希键漂移，破坏局部性 -
可提取结构化字段：用
map指令从 Cookie 或 Header 中提取固定字段，例如从Cookie: USER_ID=abc123中提取abc123
配置 consistent hash：两步写清楚
Nginx 原生支持一致性哈希，无需第三方模块，但必须显式声明 consistent。
- 在
upstream块中，先写hash $key consistent;，再列server；顺序不能反 -
$key必须是已定义的变量（如通过map或内置变量），不能是字面量字符串 - 示例配置：
map $http_cookie $user_id {
~*USER_ID=(\w+) $1;
default "";
}
upstream api_cluster {
hash $user_id consistent;
server 10.0.1.10:8000;
server 10.0.1.11:8000;
server 10.0.1.12:8000;
}
这样，所有带相同 USER_ID 的请求都会被稳定路由到同一台后端，即使增减节点，也只有约 1/N 的键需要迁移（N 为节点数），大幅降低数据重分布开销。
应对节点变更：虚拟节点提升平衡性
原生 consistent 默认不启用虚拟节点，小规模集群（如 3–5 台）容易出现哈希环分布不均，导致某些后端负载偏高。
- 可通过增加
weight隐式调节：虽然一致性哈希本身不按 weight 分配，但 Nginx 实际实现中，weight 会影响虚拟节点数量（高 weight → 更多副本点 → 更均匀覆盖环） - 生产环境建议给各节点设相同 weight（如
weight=100），避免人为偏差；若硬件差异大，可微调（如weight=120vsweight=80），比直接删节点更平滑 - 不建议手动模拟虚拟节点（如重复写 server 行），Nginx 不识别这种写法，反而可能引发配置错误
验证局部性是否生效
上线后别只看日志，要主动验证哈希行为是否符合预期。
- 用 curl 发送多个含相同 key 的请求（如固定
Cookie: USER_ID=test123），观察upstream_addr日志是否始终指向同一 IP - 临时缩容一台后端（加
down），检查原属于该节点的 key 是否按环形规则顺延至下一个节点，而非随机打散 - 监控各后端的请求数标准差，一致性哈希理想状态下应低于加权轮询（尤其在 key 分布较均匀时）
