一·缓存击穿
1·出现分析
日常生产中,我们知道数据的请求路径是从客户端出发,先查询缓存中是否存在,如果有直接返回,若没有则会把请求打入DB,进而查询出所需要的数据,如下图
但是此时便会出现一种情况,如果我们请求量非常的多,高并发时,缓存的存在就是为了提高数据的查询速度,减轻DB的很多负担,当大量请求涌入,并且缓存中没有的时候,所有的请求全部进入到了DB,此时便会出现直接击穿缓存的情形,数据库便会直接崩溃。
2·解决方案:
在缓存失效后,通过加锁或者队列来控制读和写数据库的线程数量。比如:对某个key只允许一个线程查询数据和写缓存,其他线程等待,如果加设一个互斥锁,可以保证线程之间不会互相影响,不会因为某一个线程获取了锁,其它线程就处于等待时间,也就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据。
二·缓存穿透
1·出现分析:
在使用redis缓存的时候,我们通常会通过一个key去获取对应的value,如果这个这个key一定不存在value的话,便会去DB中查询,当访问量大量请求,缓存便会被穿透,直接访问到DB,此时便会让服务器宕机,尤其是在原本知道缓存必定不存在对应的数据,强行发送大量请求的时候,便会出现缓存穿透!
2·解决方案:
1> 其实首先我们可以考虑使用布隆过滤器,将所有可能存在的数据通过哈希算法存放进一个足够大的set中,当数据不存在的时候便会被拦截掉,从避免了对底层存储系统的查询压力。这个方法的缺点时没有办法删除掉存入的比特值。
2> 如果一个查询返回的数据为空,不管是数据不存在还是系统故障,我们仍然把这个结果进行缓存,但是此时对他进行加设时间,这样定时删除,便会不会穿透缓存了。
三·缓存雪崩
1·出现分析:
因为缓存层承载了大量的请求,有效的保护了存储 层,但是如果缓存由于某些原因,整体不能够提供服务,于是所有的请求,就会到达存储层,存储层的调用量就会暴增,造成存储层也会挂掉的情况,在开发中的场景可能是:当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,大量数据会去直接访问DB,此时给DB很大的压力。
2·解决方案:
(1)设置redis集群和DB集群的高可用,如果redis出现宕机情况,可以立即由别的机器顶替上来。这样可以防止一部分的风险。
(2)使用互斥锁,在缓存失效后,通过加锁或者队列来控制读和写数据库的线程数量。比如:对某个key只允许一个线程查询数据和写缓存,其他线程等待。
(3)不同的key,可以设置不同的过期时间,让缓存失效的时间点不一致,尽量达到平均分布。
(4)redis中设置永久不过期,这样就保证了,不会出现热点问题,也就是物理上不过期。