不能直接用 hash(key) % len(nodes)，因为节点增减会导致约75%的key映射关系改变，引发缓存雪崩；一致性哈希通过哈希环+顺时针查找，使增删节点仅影响相邻少量key，配合虚拟节点可将重映射压至1%以内。
为什么不能直接用 hash(key) % len(nodes)
因为节点一增一减，几乎所有 key 的归属都会变——缓存集体失效、数据库瞬间被打穿。这不是理论风险，是真实压测里秒级雪崩的起点。一致性哈希要解决的，就是“加一台机器，只动 1/N 的数据”这个硬需求。
它的核心不是“更高级的取模”，而是把节点和 key 都扔进一个 0～2³²−1 的环里，key 顺时针找最近的节点。这样增删节点，只影响环上相邻的一小段 key。
- 普通取模：节点数从 3 变 4，约 75% 的 key 映射关系改变
- 一致性哈希（无虚拟节点）：节点数从 3 变 4，平均仅约 25% 的 key 重映射
- 加虚拟节点后（比如每物理节点配 100 个副本），重映射比例可进一步压到 1% 以内
hash/crc32 是首选，但别忘了 ChecksumIEEE
Go 标准库的 crc32.ChecksumIEEE 比 crc32.Checksum 更常用，因为前者是 IEEE 802.3 标准实现，分布更均匀、碰撞率更低，且所有语言生态（Java/Python/JS）默认也用它——跨语言协同时不会出现“同一个 key 在不同服务里落到不同节点”的诡异问题。
别手滑写成 crc32.Checksum([]byte(key), crc32.Table)，它需要显式传表，而 ChecksumIEEE 内置了最优表，调用更简洁、性能略高。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
crc32.ChecksumIEEE([]byte(key)) - 错误写法：
crc32.Checksum([]byte(key), nil)（会 panic）或漏掉IEEE - 注意：返回是
uint32，别误当成int去做算术，尤其在比较和取模时
sort.Search 找环上节点，但得处理空环和越界
哈希环本质是个升序 []uint32，sort.Search 是最轻量、最安全的查找方式——它不依赖 sort.Interface 实现，也不改原 slice，纯函数式语义清晰。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
但实际用的时候，三个边界必须手动兜底：
- 环为空：
len(ring) == 0时直接 panic 或返回 error，不能硬算i % len(ring) - key 比所有节点都大：此时
sort.Search返回len(ring)，得回绕到ring[0] - 节点 hash 碰撞：多个节点映射到同一位置，
sort.Search仍能正确找到第一个 ≥ key 的索引，无需额外去重（但添加时建议跳过重复值，避免无效冗余）
典型安全写法：i := sort.Search(len(ring), func(j int) bool { return ring[j] >= keyHash }); return ring[i%len(ring)] —— 这个 % 不是偷懒，是环形结构的数学必然。
并发读多写少，锁粒度必须拆开
真实服务里，GetNode 调用量可能是 AddNode 的上千倍。如果整个哈希环共用一把 sync.RWMutex，写操作一来，所有读全部阻塞——这不是设计，是自缚手脚。
真正可行的方案是读写分离 + 原子替换：
- 环数据本身用不可变结构（
[]uint32+map[uint32]string），每次AddNode或DelNode都生成新副本 - 用
sync/atomic.Value存储当前有效环快照，GetNode直接 load，零锁开销 - 写操作 acquire mutex → 构建新环 → atomic.Store，确保切换原子
- 别用
sync.Map存节点映射——它适合高频单 key 读写，不适合整环替换场景
虚拟节点数（replicas）设多少？生产环境建议 64～256。太少压不住倾斜，太多增加内存和排序开销；100 是个经验平衡点，够用且不拖慢初始化。
一致性哈希最难的不是写对算法，而是让环的变更真正“无感”——节点下线时请求不丢、扩容时流量平滑、健康检查失败的节点能被及时剔除又不引发抖动。这些不在哈希公式里，但在 GetNode 调用链的每一层里。
