一次线上事故的排查分享

今天早上凌晨，redis监控开始报警，差不多一分钟一次间隔，短信栏已经被刷爆了，来到公司一看监控图，发现redis的12G内存使用率已经达到了100%，随时有可能面临redis崩溃，那就出大事了。

分析问题原因

1. 首先查看代码，查询出哪些服务使用了该redis
2. 使用redis-cli --bigkeys分析出大key，从400多万的key中，筛选出四个大key,其中一个key是hash类型，这里面的key居然达到了1700多万，并且key对应的value是长字符串，可想而知，这个大key占用的内容是多么恐怖的

3、锁定问题之后，那该怎么解决呢？

• 方案一 直接del掉这个大key,简单粗暴
• 方案二 修改代码，增加新key,将流量打到新key上，然后在删除大key.

当时时间紧急，我是采取的第一种方案，理由有三：

• 本业务后并发没有太大
• 后面有读写分离的数据库做支撑
• 内存量已经支撑不住再新建一个key了

所以果断删除key,当时删除这个key足足花费了49s, 给我吓得够呛，每秒钟都提心吊胆的，因为此时redis是阻塞状态，一旦量上来了，挂掉的可就是服务了，所幸的是安然无恙。

如果换成你，你会选择哪种方案呢？

删除key后，redis使用率瞬间降低到29%，这一个key足足占用了差不多8G空间，太可怕了，这谁写的代码，我都要快骂娘了。

分析事故原因

问题虽然已解决，但是还是要查看代码，找到问题根源，到底是什么问题导致的：

• 在看代码之前第一反应是这个key肯定没有设置过期时间
• 看完代码之后，居然有设置过期时间

但是在线上发现一个奇怪的现象

利用ttl查看key的过期时间时发现
本来是86397
再次执行ttl时发现时间变成了86399 ，不但没有减少，而且还增加了两秒

问题就在与此：

hash类型只能给最外层的key增加过期时间，当有新用户访问时发现redis没有这个key,会增加自己的key到hash中，同时会刷新这个过期时间，所以过期时间一直在增加，再加上过期时间比较长，最终导致了key永不过期的假象。

问题找到了，解决起来就是简单了，缩短过期时间就可以了