不能用 hash(key) % len(nodes)，因节点增减会导致约75%的key映射失效，引发缓存击穿和数据库雪崩；生产环境必须改用一致性哈希，并确保所有节点哈希函数、replicas数、节点标识格式完全一致。
为什么不能用 hash(key) % len(nodes) 做节点分配
节点一增一减，约 75% 的 key 映射关系立刻失效——缓存集体击穿，数据库 QPS 瞬间翻几倍。这不是压测事故，是真实线上雪崩的起点。取模分片只适合节点数绝对固定的单机 mock 场景，真进生产必须换。
Get(key) 查找逻辑里三个必踩的坑
看似一行函数，线上出问题基本卡在这三处：
-
sort.Search返回的idx没做% len(m.keys)就直接下标访问 →panic: index out of range - 查找条件写成
m.keys[i] > h而不是m.keys[i] >= h→ 找不到相等值时返回错误位置，key 总是落到环上第一个节点 - 每次
Add后漏掉sort.Ints(m.keys)→keys无序，sort.Search行为未定义，结果完全不可预测
虚拟节点数量设多少才靠谱
replicas 不是越大越好，也不是越小越省事：
- 低于 50：负载明显不均，部分节点 CPU 持续 90%，其他空转
- 100～200：重映射比例可压到 1% 以内，内存开销可控（每个虚拟节点仅存一个
int+ 一次哈希值） - 超过 500：哈希环排序和查找耗时上升，但重映射收益不再显著，纯属浪费
推荐从 128 起步，上线后根据 /status 接口返回的各节点 key 分布方差微调。
哈希函数选 crc32.ChecksumIEEE 而不是 sha256
分布式缓存对哈希性能极度敏感，每秒几万次 Get 请求，哈希本身不能成为瓶颈：
-
sha256：计算慢、输出长、分布虽好但没必要——缓存 key 不需要密码学强度 -
fnv.New32a()：轻量，但实测在短字符串（如"user:1001"）上碰撞略高 -
crc32.ChecksumIEEE：Go 标准库原生支持、无额外依赖、吞吐高、分布均匀，压测中 key 落点标准差最小
别自己造轮子，就用 crc32.ChecksumIEEE([]byte(key))，别包一层再转 uint32，少一次类型转换就是少一次逃逸。
"ip:port" 而不是混用 hostname）**——只要有一处不一致，整个环就错位，问题会表现为“某些 key 总是找不到”，排查起来像在黑盒里摸开关。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
