如何解决缓存穿透问题
缓存穿透?
缓存穿透:指缓存和数据库中都没有的数据,然后就导致所有的请求都打到数据库上,但是数据库也还是查不到数据,然后就不能写入缓存,进而导致数据库短时间线程数被打满而引发其他服务阻塞,最终导致线上服务不可用。此时缓存就好像被穿透了一样,起不到如何作用。
当然,使用缓存难免会有穿透的发生。
- 缓存容量有限,不可能去缓存所有数据,查询到未被缓存的数据就会发生穿透是正常情况。
- 互联网业务的数据访问模型一般是遵循二八原则的,即 20% 的数据为热点数据,80% 的数据是非热点不被常访问的数据。既然缓存容量有限,且20%的数据为热点数据,那我们可以利用有限的容量去缓存那 20% 的数据来保护我们的系统,至于80%非热点不常用的数据发生穿透就穿透了,数据库吃得住(因为不经常访问嘛)。
其实,只有大量穿透请求超过了我们后端系统的承受范围,比如恶意的穿透攻击,这样的穿透才有可能把我们的系统给干崩。
解决办法?
既然会有恶意的穿透攻击,那我们就要提前进行预防,下面就介绍3种预防的方法。
1、参数校验
我们可以在参数校验层加上参数合法性校验。比如查询订单的ID为20位随机值,我们就可以先核对一下ID长度是否规范,如果不规范就直接过滤掉。
2、数据设置空值
如果当访问缓存和数据库都没有查询到数据,我们就把这个key当作是恶意的请求参数,然后可以将该key的空值写进缓存,再给它设置一个较短的过期时间。这样如果有大量相同的恶意请求来访问这个数据的时候,就可以直接从缓存中返回一个null值。
但是如果有大量不同的恶意请求的话,这种方式就会极大地浪费缓存空间,并且如果缓存中的null值过量的话,还会导致缓存本身存在的数据淘汰掉,这就会使我们的缓存命中率下降(因为缓存中原来的数据被淘汰掉了,就会重新访问数据库)。
3、布隆过滤器
布隆过滤器在查询缓存之前起到初步过滤作用,布隆过滤器存储所有可能访问的 key
,将不存在的 key 直接过滤,存在的 key 再进一步查询缓存和数据库。
布隆过滤器的机制是:如果判断key不存在,则一定不存在;如果判断key存在,则大概率存在(小概率不存在)。而且这个概率是可控的,可以根据需求小幅度改变概率值。
布隆过滤器由一个 bitSet 和 一组 Hash 函数(算法)组成,是一种空间效率极高的概率型算法和数据结构,通过二进制来进行数据存储。在初始化时,bitSet 的每一位被初始化为0。
当数据加入布隆过滤器集合时,流程如下
:
- 经过K个哈希函数计算该数据,返回K个计算出的hash值
- 这些K个hash值映射到对应的K个二进制的数组下标
- 将K个下标对应的二进制数据改为1。
布隆过滤器查询一个key是否在集合中,流程如下:
- 经过K个哈希函数计算该数据,对应计算出的K个hash值
- 经过hash值找到对应的二进制的数组下标
- 如果存在其中一处位置的二进制数据是0,那么该数据不存在。若是都是1,该数据存在集合中(但由于存在Hash碰撞,判断数据存在时可能存在误判)。
布隆过滤器的优缺点
优势
- 因为存储的是二进制数据,因此占用的空间很小;
- 它的插入和查询速度是很是快的,时间复杂度是O(K),能够联想一下HashMap的过程;
- 保密性很好,由于自己不存储任何原始数据,只有二进制数据
缺点
1、存在误判
添加数据是经过计算数据的hash值,hash是存在碰撞的,也就是说,存在两个不一样的数据计算获得相同的hash值。
例如图中的你好
和hello
,假如最终算出hash值相同,那么他们会将同一个下标的二进制数据改成1。因此也无法确定key为你好
和hello
是否存在。
2、删除困难
如上,你好
和hello
的hash值相同,对应的数组下标也是同样的。如果想删除你好
,即将坐标值改为0,可能会影响到其他key,比如是否会连hello
都一块儿删了之类的。
如何解决缓存击穿问题
缓存击穿?
缓存击穿
:指缓存中没有但数据库中有的数据(一般是热点数据缓存时间到期
),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去查,引起数据库压力瞬间增大
,线上系统卡住。
解决办法?
1、加互斥锁(mutex key)
。在并发的多个请求中,只有第一个请求线程能拿到锁并执行数据库查询操作,其他的线程拿不到锁就阻塞等着,等到第一个线程将数据写入缓存后,直接走缓存。
互斥锁
缓存击穿后,多个线程会同时去查询数据库的这条数据,那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它。
其他的线程走到这一步拿不到锁就等着,等第一个线程查询到了数据,然后做缓存。后面的线程进来发现已经有缓存了,就直接走缓存。
2、热点数据不过期。根据实际业务情况,在Redis中维护一个热点数据表,批量设为永不过期(如top1000),并定时更新top1000数据。
这种方式适用于比较极端的场景,例如流量特别特别大的场景,使用时需要考虑业务能接受数据不一致的时间,还有就是异常情况的处理,不要到时候缓存刷新不上,一直是脏数据,那就凉了。
如何解决缓存雪崩问题
缓存雪崩?
缓存雪崩
:大量的热点 key 设置了相同的过期时间,导在缓存在同一时刻全部失效,造成瞬时数据库请求量大、压力骤增,引起雪崩,甚至导致数据库被打挂。缓存雪崩其实有点像升级版的缓存击穿
,缓存击穿是一个热点 key,缓存雪崩是一组热点 key。
解决办法?
1、过期时间打散。既然是大量缓存集中失效,那最容易想到就是让他们不集中生效。可以给缓存的过期时间时加上一个随机值时间,使得每个 key 的过期时间分布开来,不会集中在同一时刻失效。
2、热点数据不过期。缓存永不过期,异步更新缓存数据。随不会出现雪崩效应,却无法保证数据的一致性。
3、加互斥锁。jvm锁机制、分布式锁机制都可以。该方式和缓存击穿一样,按 key 维度加锁,对于同一个 key,只允许一个线程去计算,其他线程原地阻塞等待第一个线程的计算结果,然后直接走缓存即可。