一致性哈希是1997年David Karger等人提出的环形哈希算法，通过将节点和数据映射到0～2³²−1哈希环上并顺时针查找定位，使增删节点仅影响邻近一小段数据，满足平衡性、单调性和分散性；其核心在于环结构与虚拟节点机制，而非单纯哈希函数选择。
直接用 hash/crc32 + 取模不是一致性哈希，那是普通哈希取模；真要路由稳定、扩缩容不雪崩，必须建环、加虚拟节点、用 sort.Search 查找。
为什么不能用 keyHash % len(nodes) 做路由
节点从 3 台变 4 台，约 75% 的请求会重映射——缓存全失效、数据库被打穿、下游服务瞬间超载。这不是理论问题，是压测里秒级雪崩的起点。一致性哈希的目标是：加一台机器，只动 1% 左右的 key，其余请求完全不受影响。
核心区别在于结构：keyHash % len(nodes) 是线性分片，而一致性哈希是把所有节点和 key 都“钉”在 0～2³²−1 的环上，key 顺时针找第一个节点。增删节点只影响环上邻近的一小段 key。
- 别被“哈希”二字带偏——算法成败不在哈希函数多强，而在有没有环结构和顺时针定位逻辑
- 环必须是
[]uint32（不是int32），否则负数会导致绕环异常 - 返回值必须用
i % len(ring)回绕，sort.Search返回的是索引，不是环值
该用哪个哈希函数：选 crc32.ChecksumIEEE，别碰 md5 或 hash/fnv
crc32.ChecksumIEEE([]byte(key)) 是唯一推荐：输出天然为 uint32、分布均匀、无内存分配、跨语言一致（Java/Python/JS 默认也用它），且 Go 标准库已内置最优查表，调用简洁无 panic 风险。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
其他常见错误：
-
crc32.Checksum([]byte(key), nil)：会 panic，必须传表或改用ChecksumIEEE -
hash/fnv.New32a()：无 seed 控制，易被恶意 key 扎堆攻击，不适合生产路由 -
fmt.Sprintf("%s", key)+md5.Sum：字符串转换开销大，md5 是加密级，完全没必要 -
maphash.Hash：虽快但输出是uint64，需手动截断或 mod 2³²，反而引入误差，不推荐用于环坐标
虚拟节点怎么设：20–60 个足够，别硬写 100
虚拟节点不是越多越好。实测表明：每物理节点配 20–60 个虚拟节点，即可将负载标准差压到 ±5% 以内；超过 100 后，查找延迟从 ~20ns 涨到 ~80ns，CPU cache miss 率陡增，初始化耗时也明显上升。
生成虚拟节点 hash 时，必须用确定性方式，禁止依赖 math/rand：
- 正确做法：
crc32.ChecksumIEEE([]byte(nodeName + "-" + strconv.Itoa(i))) - 错误做法：
rand.Uint32()或未设 seed 的rand.New(rand.NewSource(time.Now().UnixNano()))—— 多 goroutine 并发下极易产出重复值，导致节点在环上扎堆 - 拼接虚拟节点名时，避免
fmt.Sprintf：QPS 过万时，unsafe.String或预分配[]byte更快
sort.Search 查环的三个必兜底边界
环是数学上的首尾相接结构，但 []uint32 是线性数组。sort.Search 只负责找索引，不处理环形语义。漏掉任一兜底，线上就会 panic 或返回空。
- 环为空：
if len(ring) == 0 { return "", errors.New("ring is empty") }，不能直接进sort.Search - key hash 大于所有节点：
sort.Search返回len(ring)，必须用ring[i%len(ring)]回绕到首节点 - 多个虚拟节点 hash 碰撞落同一位置：
sort.Search仍能正确返回第一个 ≥ key 的索引，但添加时建议跳过重复值，避免冗余
典型安全写法：i := sort.Search(len(ring), func(j int) bool { return ring[j] >= keyHash }); return ring[i%len(ring)]——这个取模不是偷懒，是环形结构的数学必然。
