什么是redis的缓存雪崩, 穿透, 击穿?

目前的互联网系统没有几个不使用缓存的, 但是只要使用缓存的话就会面临这几个问题, 如使用redis缓存技术, 可能会遇到缓存的雪崩, 穿透, 以及击穿.

首先来看一个简单的正常缓存流程:

如用户访问JD, 然后JD去访问redis, 如果redis有这个数据的话,就返回回去, 显示出来,如果redis没有数据的话,他就会去请求这个数据库, 假如数据库查到这个数据之后, 数据库就会把这个结果同步到redis里面去, 同时它会把这个查询到的结果返回回去.

基于上面的流程,我们来看一下什么是redis的缓存雪崩, 穿透, 击穿?

声明: 以下例子纯属虚构, 为便于理解所编.

1.redis的缓存雪崩

举个例子, 在JD618的时候, 点进去进入到它的首页, 这个首页在618的时候访问量是非常大的, 所以很多的数据是放到redis里面去缓存起来, 对应redis的100key, 然后后台人员设置的key的失效时间是三个小时, 当这个618期间, 购物车超过三小时之后, 这个首页的redis缓存在一瞬间全部失效, 导致所有的请求都打到了这个数据库上, 造成数据库的响应不及时挂掉, 这个时候, 首页就没办法再继续对外提供服务. 这种现象就是缓存雪崩.

解决方案:

a.设置这个缓存的失效时间, 让它不要在同一时间失效, 在我们设置这个缓存的时候, 随机初始化这个失效时间, 这样的话所有的缓存就不会在同一时间失效, 把所有的请求都打到数据库上.

b.这个redis一般都是集群部署, 我们把这些热点的key放到不同的节点上去, 让这些热点的缓存, 平均的分布在这个不同的redis节点上.

c.还有最暴力的方法就是不设置这个缓存失效的时间, 让它永远不失效.

d.还有就是去跑这个定时任务, 让它去定时的刷这个缓存, 比如说我这个缓存设置了三小时时效, 那么我在失效之前, 就把这个redis缓存给他重新跑进去, 然后再设置三小时, 不断的用这个定时任务去刷新这个缓存, 这个缓存就不会失效啊.

2.redis的缓存穿透

举个例子, 比如某个网站非常的火爆, 动了某些人的蛋糕, 然后遭到疯狂的攻击, 他的攻击手段就是采用这个缓存穿透, 大家都知道数据库主键从0开始递增, 没有负数, 那么这个黑客就利用这一点, 他不断的利用这个id小于零的这个参数给我发请求, 我把数据库里面,所有的数据都放到了redis缓存中去,但是他用id小于零的数来请求, redis里面并没有这个id小于零的数据, 这样的话redis就查不到这个结果, 一旦这个redis 查不到这个结果, 就会去数据库中去查, 造成这个请求不断的打到这个数据库上, 因为中间redis这层不能拦截这样的数据, 这个redis直接被这种数据给穿透了直接穿透到数据库里面. 这种现象就是缓存穿透. redis和数据库中都没有这样的数据, 一般出现这种情况, 都是一些不正常的用户.

解决方案:

a.如果这个请求穿透了这个redis, 直接到这个数据库中, 我数据库无论查出什么结果, 是空的还是有值, 都会缓存到redis里去, 这样他下次用同一个参数来发请求的时候, 就不会穿透这个redis.

b.但是他可能换不同的参数, 这个解决方式就是把他这个ip拉黑.

c.但是他也可能换不同的ip, 然后第三个, 就是对参数的合法性校验, 在判断这个参数不合法的时候, 直接return掉.

d.第四个方法就是使用布隆过滤器, 这是一个非常好的方式.

3.redis的缓存击穿

举个列子, 东哥在618的时候想搞一个噱头, 把他自己珍藏多年的酒拿出来拍卖, 然后有非常多的人对这个酒非常的感兴趣, 在9点的时候准时拍卖这个鞋, 然后某个程序员就把酒的数据放到了redis缓存里, 对应redis一个缓存的key, 拍卖的时候呢大家都非常的热情, 一直拍卖了四小时还没有结束这个拍卖, 但是这个酒对应的缓存key, 他的失效时间是四个半小时, 当大家拍卖到四个半小时的时候, 这个酒的缓存key突然失效了, 导致大量的拍卖请求在redis里面查询不到这个数据, 这些请求就会直接打到这个数据库,上面去, 造成这个数据库响应不及时,挂掉. 这个案例呢就是redis的缓存击穿.

注意:缓存击穿是某一个热点的key.

解决方式:

a.首先想到的是让这个缓存永远不过期, 那这个方式肯定不太好.

b.使用分布式锁, 如果是单体应用的话, 就可以使用这个互斥锁.

原理: 首先大量的用户去访问这个redis的请求数据, 如果有的话就会返回给用户, 如果redis里面这个数据为空的话,就会请求这个数据库请求数据, 我们就在这个请求数据库这一步, 给他上上锁, 那么这个时候就只有一个线程, 能抢到这个锁, 所以也就只有一个线程能操作这个数据库, 那么这个时候对数据库的压力就非常小, 当他查询到这个数据之后呢, 再把这个缓存重新写到这个redis里面去, 其他没有抢到锁的线程, 让它先睡几毫秒, 然后再重新去redis里面去查询这个数据,因为我们有一个线程抢到了这个锁, 把这个数据库里面查询出来的数据放到了redis里面去, 那么其他线程在访问redis的时候, 这个redis里面就有数据了, 他就不用再去数据库里面查询数据, 他们也就不用再去竞争这个分布式锁, 他们直接在redis这一步就返回了. 所以这个是解决缓存击穿最好的一个办法.

觉得此文不错的，点赞转发，本人非常感谢！