Redis集群节点负载查看技巧

Redis集群的负载均衡不能仅依赖`redis-cli --cluster info`输出的槽位和键数分布，因为slot均匀分配绝不等于真实CPU、内存或QPS负载均衡——一个仅负责5461个slot的节点，若集中了大量热点key（如session数据）或存在大key、慢查询、过期键堆积等问题，其实际资源压力可能远超其他节点；要精准定位过载根源，必须结合`INFO memory`（关注used_memory_rss与maxmemory比值）、`SLOWLOG GET`（识别高频慢命令）和`INFO stats`（分析OPS与拒绝连接数），形成“逻辑分布+物理指标+运行行为”的三维验证闭环。

redis-cli --cluster info 是最直接、最贴近生产排查需求的方式，但它不返回“CPU 使用率”或“内存 RSS”，只反映槽位分配与键分布的逻辑负载。真要判断节点是否过载，得结合它输出的 slots 数量 + keys 数量 + slave 数量，再交叉验证 INFO memory 和 INFO stats。

用 redis-cli --cluster info 看槽位和键的粗粒度分布

这个命令本质是向每个主节点发 CLUSTER SLOTS 和 DBSIZE（或 SCAN 估算），汇总后输出每台 master 的资源占比。它比手敲 redis-cli -c -h x -p y cluster slots 更省事，但要注意：

• 必须指定集群中任一节点地址，如 redis-cli --cluster info 192.168.10.5:6379；不加地址会报错 No such file or directory
• 输出中每行形如 192.168.10.5:6379 (a1b2c3d4) -> 1287 keys | 5461 slots | 1 slaves，其中 keys 是该节点上 DBSIZE 的近似值（非精确总数，尤其启用了 LFU/LRU 驱逐时）
• 若某节点 keys 明显偏高但 slots 和其他节点一致（都是 5461 或 5462），说明数据倾斜——可能因哈希键设计不合理（如大量 user:123:* 落在同一 slot）
• 若某节点 slots 为 0，但出现在输出里，说明它被 cluster forget 过但元数据未清理干净，需人工确认是否残留

为什么不能只信 keys 数字？

redis-cli --cluster info 默认调用的是 DBSIZE，而这个命令在集群模式下只查当前连接节点的本地库，不聚合。它的问题在于：

• 遇到大 key（比如一个 hash 有 10 万 field），DBSIZE 仍只计为 1，但实际内存和 CPU 消耗远超普通 key
• 如果开启了 maxmemory 且使用 allkeys-lru，DBSIZE 不体现已驱逐 key 占用过的内存峰值
• 某些节点可能有大量过期 key 正在 lazy-expire，DBSIZE 不包含它们，但 used_memory_rss 已经涨了
• 真正要看内存压力，得单独连到每个节点执行 INFO memory，关注 used_memory_rss / maxmemory 比值

查真实负载必须补这三步

仅靠 --cluster info 会漏掉关键瓶颈。上线前或告警时，务必顺手补：

• 对每个 master 节点，单独执行：redis-cli -h -p INFO memory | grep -E "(used_memory_rss|maxmemory|mem_allocator)" —— 看 RSS 是否逼近 maxmemory
• 检查慢日志：redis-cli -h -p SLOWLOG GET 5，确认是否有高频 HGETALL 或未加 limit 的 SCAN
• 对比 INFO stats 中的 instantaneous_ops_per_sec 和 rejected_connections：如果 ops 高但 rejected 也在涨，可能是连接数打满（maxclients 不足）而非 CPU 瓶颈

最容易被忽略的是：slot 分配均匀 ≠ 负载均匀。一个只负责 5461 个 slot 的节点，如果恰好承载了所有热点用户 session key，它的 QPS 和内存可能远超其他两个同规格节点。所以 --cluster info 的数字只是起点，不是结论。

今天关于《Redis集群节点负载查看技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！