一致性哈希需配合虚拟节点、健康检查和请求路由才能稳定分摊流量；单纯替换hash(key)%N为哈希环反而因分布不均引发热点。
直接说结论：一致性哈希不是“开箱即用”的负载均衡开关，它必须配合虚拟节点、健康检查和请求路由三者协同，才能在分布式缓存集群中真正稳定分摊流量。单纯把 hash(key) % N 换成一致性哈希环，反而可能因节点分布不均导致热点。
为什么 hash(key) % N 在集群扩缩容时会崩
这是所有分布式缓存踩坑的起点。比如你有 3 台缓存节点 node0、node1、node2，用 hash(key) % 3 定位；一旦下线一台，N 变成 2，原来映射到 node2 的 key 全部重算——约 1/3 数据瞬间失效，下游服务直连数据库，雪崩就来了。
一致性哈希的核心价值不在“哈希”，而在“环上顺时针查找最近节点”这个行为带来的局部性：节点增减只影响其相邻区间，其余 90%+ 的 key 映射关系保持不变。
但要注意：物理节点数少 + 哈希环分布不均 → 虚拟节点没配好 → 某个节点实际承载 60% 流量，比取模还差。
ConsistentHashRing 实现的关键参数控制
一个可用的 ConsistentHashRing 类（无论 Dart/Java/Go）至少要暴露三个可调参数：
-
replicaCount：每个物理节点生成多少个虚拟节点，默认建议 100–200。太少（如 10）会导致环上空洞大，负载倾斜；太多（如 1000）则查找耗时上升，且内存占用翻倍 -
hashFunction：必须是确定性、低碰撞率的函数。Dart 推荐用Object.hash或md5（不要用DateTime.now().hashCode这类带时间戳的） -
nodes：节点标识必须稳定。不能传"192.168.1.10:6379"又传"redis-node-1"，否则同一节点被当两个不同节点注册进环
示例（Dart 片段）：
final ring = ConsistentHashRing<String>(
replicaCount: 150,
hashFunction: (node) => Object.hash(node).toUnsigned(32),
);
ring.add('redis-node-1');
ring.add('redis-node-2');
ring.add('redis-node-3');
final targetNode = ring.getNode('user:12345:profile'); // 返回 'redis-node-2'
在 Dio 缓存拦截器里嵌入一致性哈希路由
Dio 的 Interceptor 是请求链路的天然钩子，但别直接在 onRequest 里做哈希计算并发起远程请求——这会阻塞主线程、丢失超时控制、绕过 Dio 的重试机制。
正确做法是两层解耦：
- 第一层：用
ConsistentHashRing算出目标节点标识（如'redis-node-2'），存进options.extra - 第二层：由独立的
CacheClient（封装了 Redis 连接池 + 序列化）根据options.extra['targetNode']找对应连接，执行GET/SET
关键陷阱：onResponse 中缓存响应时，必须用原始请求的 key（而非响应体里的某个字段）参与哈希计算，否则缓存写入和读取走的是不同节点。
节点健康状态必须实时反馈到哈希环
一致性哈希环本身是静态结构，但它面对的是动态集群。如果 redis-node-2 已宕机，而环里还保留它的位置，所有本该打给它的请求都会失败或超时。
必须实现：
- 周期性心跳检测（如每 5 秒向每个节点发
PING） - 故障剔除后触发
ring.remove('redis-node-2')，且需保证多实例间环状态最终一致（可用 Redis Pub/Sub 同步变更） - 恢复后自动加回，但要加延迟（避免刚恢复就涌进大量请求）
最容易被忽略的一点：哈希环变更后，旧连接不能立即关闭，得等正在处理的请求完成，否则正在迁移中的 key 会丢数据。
