Redis集群实时内存占用分析方法

在Redis集群中精准获取某个key的实时内存占用并非易事，需绕过官方工具限制，通过CLUSTER KEYSLOT定位slot、CLUSTER SLOTS动态获取主节点地址，再直连目标节点执行MEMORY USAGE命令——但该值仅为估算，受过期元数据、ziplist编码填充、压缩特性及迁移状态影响显著；同时需严谨处理MOVED重定向、连接超时与重试，并警惕高频扫描对线上服务的冲击，真正高效的大key分析应结合--bigkeys、MEMORY DOCTOR和轻量级INFO memory聚合，而非暴力遍历。

怎么在Redis集群里查某个key的实时内存占用

单节点用 MEMORY USAGE 就行，但集群里得先知道key落在哪个slot、哪个节点上，否则直接连任意节点执行会报错 (error) CROSSSLOT Keys in request don't hash to the same slot 或返回空。

实操分两步：先定位key归属，再连对应节点查内存。

• 用 CLUSTER KEYSLOT 算出slot号（比如 CLUSTER KEYSLOT "user:1001" 返回 12345）
• 用 CLUSTER GETKEYSINSLOT 1 验证该slot是否真有这个key（可选，防slot迁移未同步）
• 用 CLUSTER SLOTS 查出该slot对应的节点IP:PORT（注意响应是数组嵌套，主节点在每组第一个元素）
• 用redis-cli -h -p --no-raw MEMORY USAGE 获取字节值

为什么不能用redis-cli --cluster memory-usage这类“一键命令”

官方 redis-cli --cluster 工具不支持 MEMORY USAGE 的透传。它能做的只是批量跑 INFO memory 或 DBSIZE，但这些返回的是节点级汇总数据，不是单key粒度。

强行写脚本遍历所有节点去查 MEMORY USAGE 也行，但必须加重试和超时控制——因为key可能刚被迁走，目标节点还没收到迁移完成通知，此时查会返回 (nil) 或报 MOVED 错误。

• 查前先 PING 目标节点，确认可连通
• 遇到 MOVED 响应，要解析重定向地址并跳转（不是简单忽略）
• MEMORY USAGE 对bigkey（如大hash/set）耗时明显，线上慎频发，建议加 --timeout 5

MEMORY USAGE返回值不准？常见偏差原因

返回的字节数是估算值，不是精确内存快照。Redis底层用近似算法（如HyperLogLog估算集合基数、采样估算字符串编码开销），尤其对以下情况偏差较大：

• 带过期时间的key：返回值不含expire元数据开销（约32字节/键），实际更高
• ziplist编码的list/hash/zset：当元素少且小，MEMORY USAGE 可能低估20%~30%，因未计入ziplist头和指针对齐填充
• 使用了 COMPRESS（Redis 7.0+ experimental）：当前版本 MEMORY USAGE 完全不感知压缩，显示的是解压后大小
• 客户端连接数多时，MEMORY USAGE 自身也会占少量临时内存，但不影响结果值

想看整个集群的内存分布热力图，有什么轻量办法

不用上Prometheus+Grafana，用原生命令组合就能快速摸清分布趋势：

先在每个节点跑：redis-cli -h $host -p $port INFO memory | grep "^used_memory_human:"，汇总后按数值排序；再挑used_memory > 80%的节点，用 MEMORY DOCTOR 看建议（Redis 6.0+）。

• MEMORY STATS 比 INFO memory 多返回碎片率、分配器统计，更准但耗CPU
• 避免用 KEYS * 配合 MEMORY USAGE 扫全量——集群里这操作等于拒绝服务
• 真正要定位大key，优先用 redis-cli --bigkeys（它内部就是分slot扫描+限速）

slot计算和节点映射关系一旦变更（比如reshard或failover），之前缓存的slot→节点映射就失效了。每次查之前，最好重新跑一次 CLUSTER SLOTS。

以上就是《Redis集群实时内存占用分析方法》的详细内容，更多关于的资料请关注golang学习网公众号！