今天早上凌晨，redis监控开始报警，差不多一分钟一次间隔，短信栏已经被刷爆了，来到公司一看监控图，发现redis的12G内存使用率已经达到了100%，随时有可能面临redis崩溃，那就出大事了。
分析问题原因
- 首先查看代码，查询出哪些服务使用了该redis
- 使用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永不过期的假象。
问题找到了，解决起来就是简单了，缩短过期时间就可以了
