Redis空间还能用多少？教你快速查剩余容量和使用情况

怎么快速查看Redis还剩多少空间？最简单直接的命令是 INFO memory，当你连接到Redis服务器后，在命令行里输入这个命令，会返回一大堆信息，你不用被这些信息吓到,只需要盯着其中一两行看就行。

根据知乎用户“Redis爱好者”在一篇介绍内存分析的文章中提到，关键指标是 used_memory 和 maxmemory。used_memory 表示Redis当前已经使用了多少字节的内存，而 maxmemory 则是你在配置文件中设定的Redis最大可用内存上限（如果没设置，这个值就是0，意味着会使用系统所有可用内存，这很危险），最简单的算法就是：剩余空间 ≈ maxmemory - used_memory。maxmemory 是0，你需要去查看服务器的总内存，再减去Redis用的和系统其他进程用的,这就稍微复杂点了。

光知道还剩多少空间就像只看钱包里还剩多少钱，却不知道钱花在哪里了一样，我们更想知道的是，这些被用掉的空间（used_memory）里面，到底是什么数据占了大头？这样才能在空间不足时有针对性地清理，这时候，另一个强大的命令就派上用场了：INFO keyspace，这个命令会显示每个数据库（比如默认的db0）中有多少个键（keys），如果发现某个数据库的键数量异常多,那可能就是问题所在。

INFO keyspace 只告诉了你键的数量，没告诉你每个键占了多大空间，Redis官方文档里描述了一个更深入的工具，叫做 redis-cli --bigkeys，这个命令会扫描整个Redis数据库，然后统计出各种数据类型（比如字符串String、列表List、哈希Hash等）中，最大的那个键是哪个，它会告诉你“最大的List键是‘user:12345:messages’，它有10万个元素”，这非常有用，因为它能直接帮你找到潜在的“空间杀手”，很多技术博客，像CSDN上的运维笔记都强调,这是快速定位大Key的首选方法。

但有时候，问题不在于有少数几个超级大的Key，而在于有数百万个微小的Key，每个Key只占一点点空间，但加在一起就非常可观了，这种情况下，--bigkeys 可能就不够用了，这时候，我们需要进行更详细的内存分析，根据开源社区的经验，最彻底的方法是使用 redis-rdb-tools 这样的第三方工具，这个工具可以对你Redis的持久化文件（RDB文件）进行分析，生成一个详细的报告，告诉你每个Key占用了多少内存，并且可以按大小、数据类型、键名模式进行排序和汇总，知乎上的一位数据库工程师在专栏里写道，他在处理一次内存溢出问题时，正是通过分析RDB文件，发现是某个业务模块缓存了大量过期的用户会话数据，这些数据键名相似但数量巨大，清理掉之后立刻释放了超过70%的内存。

除了查看具体的键，INFO memory 命令里的其他一些信息也能给我们很多提示。mem_fragmentation_ratio 这个值，它表示内存碎片率，简单理解，就像你的衣柜，虽然衣服总容量没超过衣柜大小，但如果衣服叠放不整齐，中间有很多空隙，导致新的大衣塞不进去，这就是碎片化，这个比值如果大于1.5甚至更高，说明碎片化比较严重了，虽然显示剩余内存可能还很多，但实际可能无法分配出一块大的连续空间来存储新数据，从而导致内存浪费甚至写操作失败，Redis官方文档建议，如果碎片化过高，可以考虑重启Redis实例来重整内存，或者使用高版本Redis支持的MEMORY PURGE命令（如果支持的话）来尝试清理。

知道了这些方法，我们平常应该怎么用呢？可以总结一个简单的流程：日常监控就用 INFO memory 看个大概，确保 used_memory 别太接近 maxmemory，留出一定的缓冲空间，当收到内存告警或者发现空间不足时，第一步先用 redis-cli --bigkeys 快速扫一遍，看有没有明显的大Key可以马上清理，如果问题依然没解决，或者没有发现明显的大Key，那就考虑使用RDB分析工具做一次深度体检，找出所有占用空间较多的键模式，从业务层面判断哪些数据可以优化或清理，也要留意内存碎片率，避免“虚假”的内存充足现象。

最后要提醒的是，预防胜于治疗，在开发阶段，就要有意识地优化Redis的内存使用，比如使用更高效的数据结构（用Hash代替多个独立的String键存储对象属性），给Key设置合理的过期时间，避免存储过大的单个对象等，这些良好的习惯，比事后任何高级的诊断工具都更有效，这些方法在多个技术社区，如开源中国、掘金等平台的Redis最佳实践文章中都被反复强调。