redis-cli --cluster info 仅提供槽位、键数和从节点数的粗粒度分布，无法反映真实CPU/内存负载；需结合INFO memory、SLOWLOG和INFO stats交叉验证，因slot均匀不等于负载均匀。
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，而这个命令在集群模式下只查当前连接节点的本地库，不聚合。它的问题在于：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 遇到大 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 <ip> -p <port> INFO memory | grep -E "(used_memory_rss|maxmemory|mem_allocator)"</port></ip>—— 看 RSS 是否逼近maxmemory - 检查慢日志：
redis-cli -h <ip> -p <port> SLOWLOG GET 5</port></ip>，确认是否有高频HGETALL或未加 limit 的SCAN - 对比
INFO stats中的instantaneous_ops_per_sec和rejected_connections：如果 ops 高但 rejected 也在涨，可能是连接数打满（maxclients不足）而非 CPU 瓶颈
最容易被忽略的是：slot 分配均匀 ≠ 负载均匀。一个只负责 5461 个 slot 的节点，如果恰好承载了所有热点用户 session key，它的 QPS 和内存可能远超其他两个同规格节点。所以 --cluster info 的数字只是起点，不是结论。
