如何解决Redis集群节点负载不均衡

本文介绍 Redis 集群负载不均衡的几个常见原因。很多开发者首先怀疑哈希算法存在问题，但实际上，多数情况是由于槽位分配不均匀、键设计不合理或客户端行为与真实流量分布不一致所导致。

先从槽位分配是否均匀入手。使用 redis-cli -c -h {host} -p {port} cluster nodes 可以查看每个节点负责的槽数，注意输出中每行末尾的 slot 范围，例如 0-5460。16384 个槽平均分配给 N 个 master，理想偏差应控制在 ±1% 以内。如果某个节点占用了 8000 多个槽，而另一个只有 2000，这就是明显的硬性不均，需要处理。

但不要完全依赖 redis-cli --cluster rebalance 显示的“no rebalancing needed”——该命令仅按槽数量计算，完全不考虑 key 的数量、访问频次或命令复杂度。一个槽里存 1 个大 Hash 和存 1000 个 String，压力差异非常显著。

• 使用 cluster countkeysinslot {slot} 抽样检查几个高槽号和低槽号，对比 key 的数量级
• 使用 redis-cli --bigkeys 扫描全集群，确认是否存在某个节点集中了大量 bigkey
• 如果发现某节点槽多但 key 少，很可能是因为迁移中断或故障恢复后残留了脏状态

为什么加了 Hash Tag 还是热点集中

Hash Tag（{...}）的设计初衷是让相关的 key 落到同一个槽里，但业务上一旦滥用，问题随之而来。例如所有用户会话都用 session:{uid}，而 uid 是连续自增 ID（如 100001、100002…），CRC16 对连续数字的哈希结果容易聚集在相邻槽，最终还是压到同一个节点上。

更隐蔽的问题在于：即使使用了 user:{123}:profile 和 user:{123}:orders，它们确实落到了同一个槽，但如果 {123} 是超级活跃用户，这个槽就成了事实上的热点槽——槽均衡 ≠ 请求均衡，这一点容易被忽略。

• 避免使用高集中度字段作为 hash tag，例如时间戳、区域编码、连续 ID
• 必要时在 tag 内加入扰动，如 user:{123#rand8}:profile，用随机后缀打散
• 对于超高频操作（如计数器），改用本地缓存加定期批量写入，减少集群直连

客户端为什么总连到同一个节点

node-redis、redis-py 等主流客户端首次连接时，会从配置列表里随机挑选一个节点发送 CLUSTER SLOTS，拿到槽表后缓存起来。如果这个“幸运节点”本身槽位过载（例如被手动分配了 10000 个槽），客户端后续所有路由都基于它返回的表计算——它不会因为自己慢就换一个节点重新拉取槽表。

客户端信任的是第一次拿到的拓扑，而不是实时负载。MOVED 重定向也只校验槽归属，不关心 CPU 或 QPS。所以即使节点 A 已经 95% CPU 占用，只要它还持有槽 0–5460，请求依然会照常发送。

• 上线前确保 startup_nodes 列表里至少包含每个 master 的地址，避免初始节点单一
• 生产环境禁用 skip_full_coverage_check=True，防止槽表缺失导致路由错乱
• 升级到 redis-py ≥ 4.6.0，它支持 readonly_mode=True 自动读取 slave，缓解主节点压力

真正难处理的场景，是那些既没有 bigkey、槽位也均匀、hash tag 也合规，但业务访问模式天然倾斜的情况——例如凌晨批量刷新全国城市天气数据，所有 key 都带 {city_id}，而 top10 城市贡献了 60% 的请求。这种场景下，单纯调整槽位无法解决，需要从业务层加入限流或预热策略来兜底。