一致性哈希是分布式缓存分片的必需方案，因其将节点与数据映射到0~2³²−1哈希环上，节点增减仅影响相邻区间数据，配合虚拟节点可使重映射比例降至1%以内，而传统取模分片在节点变化时会导致约75%的key重映射，极易引发缓存雪崩。
直接用 hash(key) % len(nodes) 做分片，在节点增减时会导致约 75% 的 key 重映射，缓存雪崩几乎是必然的。真要落地分布式缓存分片，一致性哈希不是“可选优化”，而是必须迈过的门槛。
为什么不能用取模分片代替一致性哈希
取模分片在节点数变化时，所有 key 的归属几乎全部失效——比如从 3 节点扩到 4 节点，原本 hash("user:1001") % 3 == 1 的 key，现在变成 % 4 == 2，归属彻底改变。压测中常见数据库 QPS 瞬间翻 5 倍，就源于此。
一致性哈希把节点和 key 都映射到同一个环上，节点增减只影响环上相邻的一小段区间。配合虚拟节点（replicas），重映射比例能压到 1% 以内。
- 真实故障场景里，
hash(key) % len(nodes)导致的缓存击穿，比代码 bug 更难定位 - 哪怕只有 2 个缓存节点，只要未来可能扩容，就该从第一天起用一致性哈希
- Go 标准库不提供现成的
ConsistentHash，得自己搭骨架，但核心逻辑不到 50 行
Go 中实现一致性哈希环的关键字段
一个可用的哈希环结构体至少包含四个成员：哈希函数、虚拟节点倍数、排序后的哈希值切片、以及虚拟节点到真实节点的映射表。
立即学习“go语言免费学习笔记（深入）”；
示例结构定义：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type Map struct {
hash Hash
replicas int
keys []int
m map[int]string
}
注意：keys 必须保持升序，否则 sort.Search 查找会失败；m 的 key 是虚拟节点的哈希值（int），value 是真实节点地址（如 "10.0.1.10:6379"）。
-
replicas建议设为 100～200，太小负载不均，太大内存浪费且无明显收益 - 哈希函数别用
sha256，crc32.ChecksumIEEE或fnv.New32a()更轻量、分布更均匀 - 每次
Add节点后必须调用sort.Ints(m.keys)，漏掉这步查找永远返回第一个节点
Get(key) 查找逻辑容易错的三个点
Get 方法表面简单，但线上出问题多卡在这几步：
正确写法是：
func (m *Map) Get(key string) string {
h := int(m.hash([]byte(key)))
idx := sort.Search(len(m.keys), func(i int) bool { return m.keys[i] >= h })
return m.m[m.keys[idx%len(m.keys)]]
}
- 没对
idx做取模就直接访问m.keys[idx]→ panic: index out of range - 用
sort.Search时条件写成m.keys[i] > h→ 找不到相等值时返回错误位置 - 哈希值类型不一致：
hash返回uint32，但keys是[]int，在 32 位系统上可能截断，统一用int64或确保目标平台一致
节点变更时如何避免查询中断
添加或删除节点本身是 O(N) 操作（N 是虚拟节点数），但只要不在请求高峰期执行，影响可控。真正危险的是并发读写哈希环结构体。
必须加锁，但粒度要细：
- 读操作（
Get）只读keys和m，用sync.RWMutex的RLock()即可 - 写操作（
Add/Remove）需Lock()，且应原子替换整个keys和m，而不是原地修改 - 不要在
Get里做defer mu.RUnlock()后续还访问字段，Go 的 defer 是函数退出时才执行
虚拟节点越多，单次 Add 越慢，但查询稳定性越高；实际部署建议 replicas=128 + sync.RWMutex，平衡扩展性与实时性。
