本文主要讲解关于记一次线上Redis内存占用过高、大Key问题的排查相关内容，让我们来一起学习下吧！

问题背景

在一个风和日丽的下午，公司某项目现场运维同学反馈，生产环境3个Redis的Sentinel集群节点内存占用都很高，达到了17GB的内存占用量。

稍加思索，应该是某些Key的Value数据体量过大，占用了过多的内存空间，我们在使用Redis的过程中，单个Value或者单个集合中的元素应该保证不超过10KB，已获取最佳的实践体验。

工具推荐

网上搜索了一番，关于分析大Key的工具还挺多，分为Redis官网工具和第三方工具。

经过一番比对，不同的工具都体验了一下，这里跳过工具之间的对比过程，直接给结论：redis data reveal。

大家可以在releases中下载打包好的应用程序，这里也给个国内加速下载地址：蓝奏云。

因为线上已经开启了Redis的RDB和AOF持久化策略，直接把RDB文件拉到本地。

如果没有开启RDB可以使用bgsave命令导出

执行RDB文件分析命令：

chmod +x rdr-linux
./rdr-linux show -p 8099 dump.rdb

等待一会儿，程序会自动对RDB文件进行分析，分析完成后会在设置的端口打开web服务，我们的RDB文件有4GB，分析耗时大概5分钟，分析过程日志如下：

start parsing...
parse dump.rdb  done
parsing finished, please access http://{$IP}:8099

打开分析报告页面，查看到的queue:sdk:audit:log占用了17GB内存，经分析后发现是由于下游消费服务未部署导致队列数据积压所致：

通过Redis集群的Slave节点，再次查看对应的key大小（字节数）：

127.0.0.1:9532> memory usage queue:sdk:audit:log
(integer) 18124761989

至此，可以确定是该Key的原因导致Redis内存占用过高，因为这个key在该项目未使用到，所有对生产者做了优化处理，并删除线上Redis对应的key。

以上就是关于记一次线上Redis内存占用过高、大Key问题的排查相关的全部内容，希望对你有帮助。欢迎持续关注程序员导航网，学习愉快哦！