redis--缓存穿透,缓存雪崩,缓存击穿。

 


1.redis缓存的由来

传统网络访问系统图:

 

当client访问量增大的时候,数据库会出现性能瓶颈,导致qps低下,解决方案:数据库集群,数据库读写分离。

理论上讲,无限新增机器,新增数据库节点,是可以解决这个问题的,但是要考虑资源成本和维护成本。故引出了我们的缓存。

缓存能提高qps的原因是:缓存基于内存运行,数据库基于硬盘运行。这里的缓存在java web中我们一般采用的就是redis。

将热点数据维护在redis中,业务层查询数据的时候优先查询redis,没有再查询数据库。


2.redis缓存会引发的问题以及解决方法


缓存穿透

如图,如果我大量的数据库和缓存都不存在的查询条件,去访问,会怎么样,业务层就会绕过redis,每次都去数据库查询一遍,从而当量上来了损耗数据库性能。这就是我们常说的缓存穿透问题

思考?解决方法,如果让这些不存在的数据在第一次查询数据库之后,缓存里面也保存起来呢

好像是防止了后续无效访问数据库的问题,但随之而来的问题是,当量大起来的时候,redis里面会存在大量的null值,而机器的内存大小是有限的,这样显然是不是长久之计。

怎么办?请看下图

在缓存里面没有查询条件的数据时候,我们在它要去访问数据库之前加上一个过滤器。来控制是否让它去访问数据库,意思就是我们提高了访问数据库的门槛,之前是缓存没有就去数据库,不,现在你得把你的身份证给我验证一下,我再决定是否放行。

那么这个验证的标准是什么呢,比如它把id=-1给我了,我总得去一个地方比对,有人说简单啊,不是说内存快吗,我事先在内存里面把数据库已经存在的id都存一遍,通过这个比对就可以了。好,如果后面有人用name,age等等一系列查询条件去查呢?难道都缓存起来吗,显然不是这样的。因为太耗内存。

怎么办?过滤器总得有个过滤条件,这个条件总得事先就有的,其实上面的思路是对的,现在要解决的是不能让它太消耗内存。bit数组,这个时候有用武之地了,某查询条件下数据库如果有值就在特定的位置标1,简单来说长度为一亿的bit数组,所占内存大小是接近12MB。这也是布隆过滤器的原理。开始上图

如上图,过滤器中定义若干个hash函数,对查询条件进行hash运算,并且与bit数组的长度取模,得到的结果位置标志1,表示该查询条件数据库里有值,可以放行。

问题:为啥要若干个hash函数,因为要减少hash碰撞的概率,那是不是hash函数越多越好呢,这样碰撞的概率也越小,当底下的bit数组长度无穷大的时候是这样的,事实,bit数组的长度是有限的,如果hash函数过多,每一个查询条件hash出来的位置个数也就越多,如果最后少量的查询条件就把bit数组给填满了,那么过滤器就无法起到作用了。

如何平衡hash函数个数,和bit数组长度呢,两个公式:

 

n表示预估数据的数据条数,p为你接受的误判率,m为bit数组的长度,k为hash函数的个数。

误判率说一下,就是两个查询条件,最后经过多个hash函数得到的值都一样,最后其实有一个查询条件其实数据库里并没有值,故此时就会发生误判。


缓存雪崩

上面加完过滤器似乎很完美了,

1.某一时刻,redis里面大量的key值失效,会怎么样,这些数据数据库里面是存在的,所以过滤器中也有,那么肯定也是会放行的,这个时候数据库面对的又是大量的访问;

2.某一时刻,做缓存的redis挂掉了,那么查询redis肯定是没有值的,过滤器中是有的,同样放行,数据库同样面临着大量的访问。

以上两种情况就是所谓的缓存雪崩现象。

怎么解决呢?

情况一:错开key的失效时间。(如果是代码删除key导致的,这个就是bug了)

情况二:redis采用高可用的集群方式,分片存储。即使挂掉了,也是部分放行。


缓存击穿

过滤器也加了,失效时间也错开了,集群也做了,完美吗?

当然是NO,想想redis中key值设置失效是很常见的,那么如果有一个极度热点的数据,在某一刻失效了导致大量访问,这个时候也会直接到数据库那边去,这个时候怎么办。首先告诉你这个问题就是缓存击穿

有人会说,既然这样,那么这个数据我不设置失效时间不就可以了吗,永远存在。想法很好,但是你怎么知道哪一个数据会是极度热点的呢?拿商品搜索来说,现在疫情,可能口罩搜的特别多,之前可能是杜蕾斯搜的比较多,再之前可能是华为搜的比较多等等,你总不能事先把这些全都设置为永久的吧。或者说你代码逻辑某一时刻删除key的情况也是存在的。

问题来了,怎么解决。先上图

大量的客户端都要去数据库拿黄金万两这条数据,方法:加锁,一个一个来。

如果只有一个jvm,内置锁,显示锁都行。

如果是多个jvm那么就要来分布式锁了。主流分布式锁有:基于数据库分布式锁,基于redis分布式锁,基于zookeeper分布式锁。

分布式锁图,有图就是好哈,client拿完锁之后,如果睡着了,或者说挂掉了怎么办,锁没有还,后面的client不就只能干等着吗,好,我设置过期时间,那么设置多长呢,还有就是说拿锁的人挂掉了,是不是其他的人至少要等你所设置的过期时间才行呢。

其实上面有两个问题,一个是过期时间不好设置,二是其他的客户端需要时不时过来看看锁是否释放掉了,这就是基于数据库和redis实现分布式锁存在的问题。

故这里我决定采用zookeeper规避掉这些问题。

zookeeper如此强大吗,对是的,我说的,怎么实现,临时顺序节点,事件监听回调函数处理。

一,不用设置过期时间,zookeeper有心跳机制进行检测节点状态,模式是2秒检查一次可以设置,如果节点挂掉了,它所对应的临时节点会被删除,那么它的下一个节点会进入到自己的回调函数当中去。

二,没有拿到锁的client,不用去轮训看看可不可以拿到锁,采用事件监听,每一个client只需要监听自己的上一位就可以了,就像银行加号一样,你是8号,那么只要关注7号有没有完事儿就行。


总结:

基本上,关于redis缓存,为什么用,有哪些问题都说明白了,其实不难发现,缓存雪崩和缓存击穿其实本质就是缓存穿透,只不过是特殊情况下发生的缓存穿透。就是绕过了缓存直接访问数据库,导致数据库顶不住的问题。好了,该博客,写于世界疫情的当前,希望疫情早日结束,A股也早日重回3000点,各位程序员同胞们都能有一份好的工作,莫道浮云终蔽日,严冬过尽春蓓蕾。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值