仅靠移动槽位无法解决cpu压力不均，因它只调整数据分布而非请求分布；但它是负载均衡的前提。redis-cli --cluster rebalance显示“no rebalancing needed”却仍有cpu差异，因其仅按槽数量是否均衡判断，不考虑key数量、访问频次或命令复杂度。
Redis Cluster客户端为什么总连到少数几个节点？
因为默认的 node-redis 客户端（v4+）在初始化连接时，会随机选一个节点发起 CLUSTER SLOTS 请求，拿到槽位映射后缓存下来——但这个初始节点如果恰好是槽位分配不均的节点（比如被手动分配了 8000+ 槽），后续所有键路由都会基于它返回的槽表做计算，而不会主动探测其他节点是否更“轻”。这不是负载不均的根源，而是“感知盲区”的起点。
Random节点选择策略的真实行为
所谓“随机选节点”，仅发生在首次建立连接或集群拓扑变更后刷新槽表时。它不等于“每次命令都随机挑节点发请求”。实际流程是：
-
node-redis从配置的节点列表中随机挑一个（比如192.168.1.10:6379），发送CLUSTER SLOTS - 该节点返回完整槽位分配表（如
[[0,5460,"192.168.1.10",6379], [5461,10922,"192.168.1.11",6379], ...]） - 客户端本地构建
slot → node映射表，并长期缓存（直到收到MOVED或ASK重定向）
问题在于：如果初始节点本身槽位过载，它返回的槽表虽正确，但客户端不会因“这个节点太忙”就换一个节点重新拉槽表——它信任第一次拿到的拓扑。
MOVED重定向为什么不能自动平衡负载？
MOVED 是被动纠错机制，不是负载调度器。它的触发条件非常明确：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端计算出目标槽应在节点 A，但发给了节点 B
- 节点 B 发现自己不负责该槽，返回
MOVED 12345 192.168.1.12:6379 - 客户端更新本地槽表，把槽 12345 指向新地址，然后重试命令
关键点：MOVED 不关心节点 CPU、内存、连接数或 QPS；它只校验槽归属。即使节点 A 当前 QPS 达 90%，只要它仍持有槽 0–5460，就不会触发任何重定向——客户端依然会持续往它身上打请求。
真正影响均匀性的三个隐藏因素
均匀性差往往不是算法缺陷，而是部署和使用方式导致的隐性偏差：
-
键设计带强热点：比如大量使用
user:{123}:profile，而{123}落在同一个槽，导致单槽数据量爆炸，进而压垮对应主节点 -
槽位分配未人工干预：用
redis-cli --cluster create默认均分，但若节点硬件不一致（比如 2 台 32G 内存 + 1 台 8G），小内存节点容易成为瓶颈，而槽表本身不反映资源水位 -
客户端未启用
enableOfflineQueue和retryDelay：网络抖动时，node-redis默认丢弃请求而非排队重试，造成瞬时流量倾斜到剩余可用节点
这些细节比“要不要换哈希算法”更常决定你看到的负载曲线是不是平的。
