一致性哈希通过环结构+虚拟节点+顺时针查找将重映射比例压至1%以内，手写易出错，推荐使用hashicorp/consul/api/consistent，需注意导入路径、Rebuild()调用、虚拟节点数设置、哈希函数选择、并发安全及健康检查。
直接用 hash(key) % len(nodes) 处理扩容，节点数一变，约 75% 的 key 就会映射错位——缓存全失效、数据库被打穿是分分钟的事。一致性哈希不是“更高级的取模”，而是靠环结构 + 虚拟节点 + 顺时针查找，把重映射比例压到 1% 以内。
为什么不能自己手写哈希环逻辑
自己实现容易漏掉环形回绕、空环判断、重复哈希去重等边界，线上一跑就 panic 或返回空节点。真实服务里，Get() 调用量可能是 AddNode() 的上千倍，但凡一处没兜底，流量就打飞。
- 环为空时调
sort.Search会 panic，必须提前if len(ring) == 0检查 -
keyHash大于所有节点哈希值时，sort.Search返回len(ring)，不手动% len(ring)就越界 - 多个虚拟节点哈希碰撞到同一位置，不跳过会导致冗余节点堆积，查找变慢、内存虚高
用 hashicorp/consul/api/consistent 是最省心的选择
它不依赖 Consul，纯 Go 实现，轻量、线程安全读多写少、已通过生产验证。导入路径必须是 github.com/hashicorp/consul/api/consistent，漏掉 /consistent 会报 cannot find package。
-
AddNode("node-a", nil)后必须调Rebuild()，否则节点不生效，Get()总是返回空或 panic - 虚拟节点数设 20–60：太少（如 10）负载不均；太多（如 200+）
Rebuild()变慢、CPU cache miss 率陡增 - 哈希函数只用
crc32.ChecksumIEEE([]byte(key))：返回值是uint32，可直接用于环坐标，跨语言也一致；别用crc32.Checksum([]byte(key), nil)，它会 panic
动态扩容时必须加锁，且健康检查不能少
consistent.Map 并发读安全，但 AddNode()、RemoveNode()、Rebuild() 必须互斥。多 goroutine 同时扩缩容，不加锁会导致环状态撕裂——部分请求看到新节点，部分还卡在旧拓扑。
立即学习“go语言免费学习笔记（深入）”；
- 节点上线后，要
Ping()验证连通性，失败连续 3 次才标记为不可用 - 下线节点要从
map[string]*redis.Client中删除，并显式调client.Close() -
redis.Client.PoolSize应按单节点吞吐预估（比如单节点扛 5k QPS，设为 30），不是按集群总量算
最容易被忽略的是：TCP 连接未断开 ≠ 节点可用。网络闪断后，一致性哈希仍可能把请求路由过去，结果卡死或超时。健康检查不是锦上添花，是动态扩容的前提。
