一次Redis问题排查

一次Redis问题排查_KimmKing的技术博客-CSDN博客_redis问题排查

早上发现单体版系统客户普遍反馈闪退，架构师查看了一下是Redis满了导致的。登录的session信息放到了Redis，问题出现在满了以后，新的登录信息写不来。用得是阿里云的Redis服务，已经做了续费升级，一个月后生效，现在直接做扩容来不及了，试了一下由于前一个订单已存在，升级失败。

紧急处理，先清空Redis所有数据，这时单体版系统可以登录了，但是发现部分功能无法使用，只恢复了系统80%的可用功能，排查了一下发现是由于一部分的页面模板也放到了Redis，清空后拿不到模板了。赶紧重启一下模板项目，写入到Redis，系统恢复。

既然出现了紧急的严重问题，那么后续的安排与总结是必须的：
1、安排开发团队分析问题，把使用情况搞清楚，
2、把上面的紧急处理过程作为一个步骤，写到wiki上，
3、同时要求添加Redis使用率监控，短信通知，

Redis使用主从配置，2G，总容量较小，但是考虑之前一直只使用了100多M，所以没有立即扩容，然后配置了一个月后续费自动加到4G。
从3周前开始，Redis的使用量直线上升。因为没有做预警，一直没发现有问题。

单体版和连锁版共用一个Redis，db0为单体，使用量不大，db1为连锁有229万个keys（占用1.7G），导致使用率太高。
Redis里的数据有3种：
- 登录session信息，用来做多台机器间的session共享，有过期时间，单体1天，连锁30天，
- 页面模板数据，几百条，用来渲染页面，静态数据，不过期，占用很小；
- 业务Code，操作期间的暂存数据等，这些数据有过期的、有不过期的（业务完成后删除）。

用户每一次显式的登录，都会创建一个新的session id，从而导致在Redis有一个新的记录，所以单体版里设置过期时间一天是比较合理的。用户每天下班关机，第二天上班至少登录一次系统，肯定有至少一次登录（其实远远不止，根据统计用户每次登录平均使用18分钟，活跃用户一天可能会登录5-10次）。

根据观察发现，基本每天登陆信息的key增长约为8万，一个月才过期导致最终出现问题。
这说明我们对缓存的使用缺乏必要的指导原则，容量预期和监控手段。
1、监控预警：设置使用超过90%做预警通知，通知架构组和开发人员。
2、设计原则：原则上Redis上的数据必须有过期时间，除了不会变动的静态数据（模板等）外，其他数据每加入一条没有过期时间的，都会造成资源减少，时间长了再说资源也不够用，所以一定要设置过期时间。对于登录session信息，一天足够了。对于暂存等临时数据，2-3天足够了。一个表单，客户输入一半，2天还不处理，肯定对他不重要，3天不处理，客户自己都忘记了，清空数据对客户影响不大。如果必须要长期保存，考虑入MongoDB或MySQL这种可以落地的存储即可。
3、紧急策略：制定紧急处理策略，清空连锁的db1数据操作步骤。
4、容量策略：每次上线一个需要使用缓存资源的功能，需要预估使用的容量，好提前安排扩容。
5、隔离策略：对于不同应用，不同用途的缓存数据，应该使用不同的Redis实例，避免系统相互干扰。
6、过期策略：调整Redis超过最大内存时的过期策略，从LRU+过期时间，改成LRU，这样内存满了以后，会先讨论近期没有使用过的冷数据。从而达到不影响业务的目的。