一致性哈希算法是解决分布式系统中键（key）到节点映射平衡问题的有效方案，通过哈希环与顺时针查找机制，使节点增减仅影响局部数据；引入虚拟节点可缓解物理节点分布不均导致的负载倾斜，广泛应用于Memcached、Redis集群、CDN调度等场景。

一致性哈希不是为“变量分布”设计的，它解决的是键（key）到节点的映射平衡问题。分布式系统中没有所谓“变量分布”，只有数据项（如缓存条目、文件、请求）按其唯一键进行路由和存储。理解这一点，是用好该算法的前提。

为什么传统取模哈希在分布式中容易失衡

比如用 hash(key) % N 分配请求到 3 台 Redis 节点，看似均匀。但一旦下线一台机器，N 变成 2，所有 key 的余数结果几乎全部改变——原来落在节点 0 和 1 的数据，现在要重新算 % 2，约 50% 的 key 会跳转，大量缓存失效、数据库被打穿。

这种全局重散列导致：
• 请求错位（命中率骤降）
• 存储错位（数据找不到）
• 迁移成本高（需人工或后台同步搬数据）

一致性哈希如何实现“小范围影响”

它把整个哈希空间看作一个首尾相接的环（0 到 2³²−1），然后：
• 所有节点（如 192.168.1.10）经哈希后落在环上某一点
• 所有 key（如 "user:12345"）也哈希后落在环上另一点
• key 沿环顺时针走，落到第一个遇到的节点上

这样，增减节点只影响该节点与前一节点之间的那段弧区间。例如移除节点 B，原先由 B 负责的 key，只会被其顺时针后继节点 C 接管；其余节点上的 key 完全不受影响。

真实场景中必须加虚拟节点

直接把物理机映射到环上，常出现“三台机器，两台负载 80%，一台仅 10%”——因为 IP 哈希值天然聚集，环上分布不均。

解决方法是每个物理节点生成 100–200 个虚拟节点（如 node1#0、node1#1…），再各自哈希入环。效果：
• 物理节点越多，虚拟节点越能摊薄热点
• 单台机器故障时，其虚拟节点负载自动分散到多个邻近物理节点，避免单点过载
• 扩容时，新机器的虚拟节点均匀插入环中，数据迁移更平滑

典型落地场景与关键配置点

Memcached/Redis 集群客户端路由
• 不依赖中间代理，由 SDK 自行计算 key → node 映射
• 必须使用相同哈希函数（如 MD5 + 低 32 位）和相同虚拟节点数，否则多语言客户端结果不一致

CDN 边缘节点调度
• 用户请求按 URL 或 client IP 哈希，固定路由到地理邻近的 POP 点
• 节点上下线时，仅局部用户重定向，不影响整体命中率

HepyCloud 等分布式存储系统
• 文件 key 经 Davies-Meyer 哈希后定位存储设备
• 23 台设备实测文件数标准差

Dragonfly P2P 下载的 Seed Peer 路由
• v2.4.0 SDK 用一致性哈希替代 Kubernetes Service 随机转发
• 同一文件 hash 总落到相同 seed，提升本地缓存复用率，降低源站压力