共计 1029 个字符，预计需要花费 3 分钟才能阅读完成。
记录一次线上 redis 占用过大的排查过程，供后续参考
测试同事突然反馈测试环境的 web 系统无法登陆，同时发现其他子系统也存在各类使用问题
1、因为首先反馈的是测试环境系统无法登陆，于是首先去查看了登陆功能的报错信息，一查看服务器日志首先发现了 redis 集群宕机的问题
同时也有其他的一些 redis 相关报错
2、由此可知，肯定是 redis 出现了问题，那么进一步排查 redis 节点情况
3、因为 redis 部署的是集群，首先到服务器上通过 top 指令查看了各个节点的内存、cpu 占用情况
4、结果发现有两个节点的内存占用高达 15G
5、单独登陆这两个节点，通过 INFO 指令查询节点详细状态
redis-cli -p <端口>
INFO
6、结果发现这两个节点的内存占用确实异常，而且这两个节点是主从节点。那么问题到这里有基本清晰了，以下基本就是两个方向：
-
- 产生了大量的 key，没有及时清理导致内存占用过多
-
- 某几个 key 其值异常大，没有及时清理导致内存占用过多
但这里其实偏向于第 2 点，因为是集群模式下某一主从节点都出现该问题，说明是某一个 hash 段的 key 分配到这个节点上的很大。
通过通过 INFO 指令查询到 redis 中占用的 key 数量只有 1 百多万，不算很多，所以基本也定位到是第 2 点的可能性了。
7、要查询是否有占用内存较大的 key, 可以通过 bigkeys 指令。如下图所示，可以看到其中 jms_log_list 的 key 占用内存高达 50%
redis-cli -p <服务端口> -a <认证密码> --bigkeys
再详细查询这个 key 的占用空间，单位 bytes，换算下来将近 10G
memory usage
8、到这里问题就基本明朗了，通过 key 值去查询代码，发现这个数据是 list 类型的，其作用就是作为一个临时队列。再去查看这个队列的消费者，发现这个服务没有正常消费
9、到服务器上查看消费者服务的状态，发现服务并没有运行。经调查为上周末测试服务器机房断电后，启动服务时把这个消费者服务漏了，经过几天的运行，数据累计到一定地步导致内存占用过大了。从而影响了整个 redis 集群的运行。
10、后续关掉了一个从节点，让主节点有足够的内存空间可以运行，同时把消费者服务启动起来了，为了加快消费，还临时增加了消费者的节点数，主节点消费完成后再将从节点启动起来，让从节点逐步同步主节点的数据
11、最终解决问题，由此引申出一个 redis 内存占用过大的问题排查思路，也提醒我们，完善测试环境的开机自启脚本，同时遇到此类问题，要结合服务器情况，耐心思考、解决问题。
