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% 的请求。这种场景下，单纯调整槽位无法解决问题，必须从业务层增加限流或预热策略来兜底。