redis引发的一次生产事故

电玩女神 2024-03-25 22:18 15阅读 0赞

##  ##

#### 问题描述： ####

发版后回归测试，不定时出现token失效，导致自动退出到登录界面。

如果操作的人员较多，token失效的就比较快，操作的人员较少token失效的相对较慢。

#### 问题复现： ####

同一账号多人操作：很快就会出现token失效

不同账号多人操作：很快就会出现token失效

单个账号操作：较长时间出现token失效

#### 问题排查： ####

检查和token相关的一系列配置，查看是否配置问题

*  token的有效时长：设置的是48小时-----正常
 *  是否允许多个登录：设置允许多方登录-----正常

token是存储于redis缓存中的，重新登录，检查生成的token是否正常存储于redis。redis中新生成的token的过期时间是48小时左右，所以可以排除自身到期淘汰的原因。

让开发人员检查代码中是否有token相关的操作。

都不是这些原因，所有能想到的都已经排除了，真的头大。

再次让业务人员一起操作，然后我也登录，记录自己的token ，redis中token信息一切正常，再次退出登录的时候发现redis中这个token也消失了。

**这时候可以确定 是redis中的token丢失而导致失效，从而退出登录。**

至于为什么会丢失，还是没有头绪。

#### 确认原因 ####

然后问了下运维同事，帮忙看看redis有什么特殊的情况，这一看就有结果了：**redis内存基本快满了**，而且没有做预警，大家都不知道。

查了下有什么大key或者热key占用了这么多的内存

![format_png][]

发现系统中另一个服务占用了redis极大的内存，如下

![format_png 1][]

> 这个服务是公司基础架构的服务，里面的功能日志是通过redis模式传输的，然后在读取redis落库以达到异步解耦。落库成功就会删除redis, 而且有个定时任务负责落库，删除redis。而我们因为不了解细节 没有启用这个定时任务(也可以说压根不知道这玩意的存在)，才导致了这个结果。
> 
> 为什么就不能设置一个过期时间呢，为什么！

直接让运维同事删除这些缓存，然后多人操作系统 再试试是否会出现token失效，结果是一切正常，也不会退出登录了。

#### 为什么 ####

> redis内存不足，为什么会删除我的数据而不是报写入错误呢

这个就和redis的内存淘汰策略有关了, redis默认的淘汰策略是`noeviction` **不淘汰数据，新增或者修改操作抛异常**，而我们的环境设置的是`volatile-lru`

![format_png 2][]

redis是内存工具，所以在内存快要用完的时候，怎么去取舍已存入的数据和即将要存入的数据，redis官方提供了8种淘汰策略，配置是`maxmemory-policy` 。

所有的策略如下

*  volatile-lru：在设置过期时间的数据中淘汰最少使用的数据。
 *  allkeys-lru：在所有的数据中淘汰最少使用的数据。
 *  volatile-lfu：在设置过期时间的数据中淘汰使用频率最低的数据。
 *  allkeys-lfu：在所有的数据中淘汰使用使用频率最低的数据。
 *  volatile-random：在设置过期时间的数据中淘汰任意随机数据。
 *  allkeys-random：在所有的数据中随机淘汰数据。
 *  volatile-ttl：在设置过期时间的数据中淘汰最早过期的数据。
 *  noeviction：默认策略，不淘汰数据，新增或者修改数据会抛异常，但是读操作正常进行，不受影响

所以对于redis的使用需要小心，

**避免写入没有过期时间的数据！即使一定要存入永久数据，也要预估数据的大小，判断是否会随着时间不断增加！增加内存监控，设置报警阈值，提前发现问题。**

[format_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/479ba671368f4a93845f249fd5b0d481.png
[format_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/ed383a4e52204279a69fa91d07154a37.png
[format_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/25/1eb85a2cc36c420fb2f8025512029a3c.png