Redis 热Key、 穿透、雪崩

高并发的情况会给系统带来很高的访问流量,这就给存储这些热点信息的Redis数据造成了一些压力。

热key问题及解决方案
产生原因
用户消费的数据远大于生产的数据 (热卖商品、热点新闻、热点评论、明星直播)等。

在日常工作生活中一些突发的的事件,例如某明星突然宣布恋情,导致某新闻点击量瞬间变大,请求远超过对数据的写入。就会造成热数据问题。

我们 一般采用缓存 + 过期时间的策略来帮助我们加速接口的访问速度,减少了后端负载,同时保证功能的更新,一般情况下这种模式已经基本满足要求了。

但是有两个问题如果同时出现,可能就会对系统造成致命的危害:

访问的数据是一个热点key
构建缓存需要时间
以上两个问题如果同时出现,就可能会造成缓存失效问题,有大量线程来构建缓存,造成后端负载过大,严重还会导致系统崩溃。

在这里插入图片描述

上图简单描述了访问热点key及构建缓存的一个过程。

解决方案
解决热点key问题,可以有以下几种方案,

1、互斥锁

在上图查询数据库的过程,只让一个线程独占,这个线程构建缓存的过程,其他线程都要等待,直到第一个线程构建完成可以从中读取数据。

2、提前使用互斥锁

提前使用互斥锁,和互斥锁差不多,都是让一个线程独占构建缓存,不一样的是,在构建缓存的时候。

在value内部设置一个超时值timeout1,这个过期时间比实际的缓存过期时间短。

当从缓存中读到timeout1已经过期的时候,就认为数据也快过期了,直接执行查询数据库,进行构建缓存的过程。

这样在所有快过期的数据前,就重新构建了缓存。

3、永远不过期

永远不过期有两点

a、从redis上看,确实没有设置过期时间,这就保证了,不会出现热点key过期问题,也就是“物理”不过期。

b、从功能上看,如果不过期,那不就成静态的了吗?所以我们把过期时间存在key对应的value里,如果发现要过期了,通过一个后台的异步线程进行缓存的构建,也就是“逻辑”过期

可能会出现的问题,就是会出现老数据,怎么说?

有1、2、3、4个线程,在第2个线程时,发现value中数据已经过期,通过异步更新重新构建缓存,前面有说过,线程构建缓存会需要一定时间,如果在第4个线程执行时才完成构建,那么第2、3个线程输出的就是老数据。不过对于一般的业务需求是可以接受的。

穿透和雪崩
缓存穿透
什么是缓存穿透?

在客户端和数据库中间增加一个缓存层,如果这个缓存层中保存的都是数据库命中数据,如果服务层并没有返回数据保存到缓存中,而客户端一直在访问这个数据,则每次都要直接访问数据库,在流量小时没有问题,如果流量非常大或有恶意攻击,就会利用这个漏洞,使服务端的压力增大,严重会导致系统崩溃。

解决方案

1、把查询结果为空的结果也放到缓存中,设置很短的缓存过期时间,不超过5分钟;

2、增加一个bloomfilter,任务某个key不存在,则不访问数据库;

缓存雪崩
什么是缓存雪崩?

雪崩是设置缓存失效的时间相同,造成大量的数据在短时间内同时失效,这样访问数据库的压力也会陡增。压力这么大,就像是发生了雪崩一样。

解决方案

1、采用加锁或消息队列,采用单线程的方式,防止失效时大量线程请求数据库。

2、在同样的缓存失效时间上,增加一个随机值,这样每个缓存的过期时间的重复率就会降低很多。

3、保证缓存的高可用。例如Redis Sentinel 和 Redis Cluster

淘汰机制
保存在内存中的缓存数据如果过期或失效,为了更合理利用内存空间,提高内存使用效率。

什么是淘汰机制

在内存中保存的Key被清除掉,

(1)定时去清理过期的缓存;

(2)当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。

可以通过redis.conf设置# maxmemory 这个值来开启内存淘汰功能

redis数据淘汰策略
volatile-lru 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰
volatile-ttl 从已设置过期时间的数据集中挑选将要过期的数据淘汰
volatile-random 从已设置过期时间的数据集中任意选择数据淘汰
allkeys-lru 从所有数据集中挑选最近最少使用的数据淘汰
allkeys-random 从所有数据集中任意选择数据进行淘汰
noeviction 禁止驱逐数据

原文:https://blog.csdn.net/mayfla/article/details/80112241

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页