为什么直接用 hash/crc32 + 取模会出问题
一致性哈希不是“取模的升级版”，而是为了解决节点增减时大量 key 重映射的问题。普通取模在加一台机器后，几乎所有 key % N 都会变，缓存击穿、数据库压力陡增——这在分布式缓存或分片存储里是致命的。
真正要用一致性哈希，核心是把节点和 key 都映射到同一个环上，靠顺时针找最近节点来路由。Go 标准库不提供现成实现，得自己搭骨架。
- 别用
math/rand做虚拟节点随机分布：它默认没 seed，多 goroutine 并发调用可能产出重复 hash 值，导致节点在环上扎堆 - 虚拟节点数别设太高（比如 100+）：虽然能提升负载均衡度，但查找时遍历成本上升，
sort.Search虽快，但环大了 cache miss 也明显 - 节点名必须稳定：如果传入
"node-1:8080"，下次改成"node1:8080"就算新节点，老数据全找不到
用 sort.Search 实现 O(log N) 查找的关键细节
一致性哈希环本质是个有序 uint32 切片，查找就是“找第一个 ≥ key hash 的节点位置”。Go 的 sort.Search 正好干这事，但容易写错边界。
常见错误是把 key hash 直接塞进环里二分，结果环被污染；正确做法是只查，不改环。
立即学习“go语言免费学习笔记（深入）”；
- 环必须预排序且只读：初始化后用
sort.SliceStable(nodes, ...)排一次，之后所有查找都基于这个切片 -
sort.Search返回的是索引，不是值：要手动取ring[index%len(ring)]，否则越界 panic - 环为空时
sort.Search返回 0，必须提前判空，不然ring[0]panic
ring := []uint32{123, 456, 789}
keyHash := crc32.Checksum([]byte("user_123"), crc32.Table)
i := sort.Search(len(ring), func(j int) bool { return ring[j] >= keyHash })
node := ring[i%len(ring)] // 注意取模
并发安全不能只靠 sync.RWMutex
加锁太粗放会卡住整个哈希环——比如一个 goroutine 正在 AddNode，其他所有 GetNode 全得等。实际中读远多于写，得拆开。
推荐用“写时复制”（copy-on-write）：每次增删节点都生成新环，原子替换指针。比锁更轻，也避免读写互斥。
- 别在锁里做耗时操作：比如解析节点地址、拨号测试，这些该前置验证，不在
AddNode临界区里做 - 环变量必须用
atomic.Value或unsafe.Pointer原子更新：直接赋值 struct 指针不保证可见性，旧 goroutine 可能一直读到 stale 环 - 老环对象不会立刻回收：GC 会处理，但若环里存了大对象（比如带连接池的 struct），得确保没引用残留
真实服务中绕不开的节点健康状态管理
一致性哈希环本身不感知节点死活。K8s Pod 重启、网络抖动、进程 OOM——这些都会让环上的节点“活着但不可用”，请求照样打过去，超时堆积。
必须外挂健康检查，但别侵入哈希逻辑：把“选节点”和“用节点”解耦。
- 选节点阶段只看环结构，不做连通性校验：否则每次
GetNode都 dial，延迟爆炸 - 业务层拿到 node 后，应走自己的熔断/重试逻辑：比如用
gobreaker包包装底层 client，失败自动降级到备用节点 - 健康状态变更要异步通知环更新：比如 etcd watch 到节点下线，触发
RemoveNode，而不是轮询 ping
环的设计再漂亮，挡不住下游节点挂了还硬塞请求。一致性哈希解决的是“怎么分”，不是“分给谁”。这两层得分开想、分开压测。
