今天有个做后端的同学(神州数码的实习生)问我:一闪,这个Redis的缓存问题三兄弟你搞过没有?
咱们老实人,说实话是没遇到过,但是出于防范,都设计过,只是大概率运行的时候都没用上.
主要是平台太低,压根遇不上这种事,特别是缓存击穿,怎么说也要百万日活的平台才能把数据库给打爆吧?
不扯淡了,一个一个来聊聊
目录
缓存穿透
先来一个业务场景.比如说咱们做的就是个电商,人家用户拿一个商品id来查询了
先查Redis缓存,查不着再去查数据库,如果找到了,就把商品id缓存到Redis里面(设定一个过期时间,看具体情况),如果数据库查出来为空,那就不缓存这个商品id
这时候人群中钻出一个光头,他拿着商品id为99999999999的来查询,这时候咱就傻眼了,我们这几万日活的小平台哪来的这么大的商品id(所以肯定查不到)??
查询的时候Redis没查到,又去数据库里查,然后没查到,也不能缓存到Redis
这时候这个光头喊了几千万个弟兄一起来查,你就会发现,所有的查询请求全部都被打到了你的数据库上,因为你的Redis上没有这个id的缓存,数据库查不到,自然也不会把它缓存到Redis,然后你的数据库服务器就冒烟了~~~
当然了,说到这个份上你肯定也知道怎么解决了--把查询出来结果为空的商品id也缓存到Redis不就好了,大不了我给它的过期时间短一点嘛!
很好,确实,这个问题就基本上解决了.好像不怎么难????
缓存击穿
这个问题就和我刚刚说的一样,不到千万百万日活,想要因为缓存击穿而把数据库打冒烟,确实是有一定的难度.
也来一个业务场景,咱们还是一个电商公司,咱们啥都卖,但是这十几天,我们的某米手机做活动,一台比拼大大便宜200多,导致很多很多米粉来咱们平台买手机,搜索的都是MI 99这个商品,所以这个商品就被咱们定义为"热点数据",也就是说同一时间有大量的请求都来查"MI 99"这个商品ID
幸好啊!它被缓存在Redis里面了(暗暗高兴),所以一点问题也没有
结果下一秒,"MI 99"在Redis中的生命周期时间到了....它过期了.....
一瞬间,所有查询"MI 99"的请求全部冲到了你的数据库上.....这就造成了缓存击穿
说到这里你有知道了!咱给"MI 99"设置永不过期!! 很好,又答对了,但是听说有个互斥锁的概念,可以用来解决,但是咱们还是那句话,能跑,咱就不改~~~~
缓存雪崩
这个就有点尴尬了,这是是有可能真的给你数据库干爆的问题了
由轻到重咱来慢慢分析
再来个场景.咱又是电商公司了.然后八点准时开始卖预售,十二点准时结尾款(看起来好像很合理?)
然后八点钟咱有一波查询的小高潮,然后很多商品都被缓存到了Redis上
结果有个新来的实习生.....他设置的过期时间是4个小时....(实际不可能这么长)
也就是说,八点钟缓存进去的数据,会在十二点很准时的一起过期..哦豁~~此时你的缓存数据一下子就全没了,然后所有的请求又去找你的数据库了.....然后每四个小时一个循环,你的数据库就四个小时高占用率一次......这就是咱的缓存雪崩
某同学:不对啊,你这八点钟预售的并发都扛住了,十二点结尾款怎么就崩掉了??
来一个场景,咱们逛完预售,是不是就去打王者了?十一点五十八分再回去准备付尾款?所以在十一点前后,很有可能会访问量减少的比较大.然后很多商品的缓存在过期了之后,并没有被即使重新缓存到Redis,所以可能十二点的压力比八点的压力大
怎么解决这种雪崩呢????咱把不同品类商品的过期时间分分开,这样就不会同时过期了,比如餐巾纸一个小时,纸尿裤半个小时....
OK,这是第一种雪崩,很难干废数据库
第二种就是缓存服务器直接崩了(啥问题导致的咱也不知道,说不定是运维用服务器煎鸡蛋吃了),这个时候你直接连Redis都没有了.....这个时候你的数据库就很有可能瞬间被送走了~~~
这种怎么解决呢.......这我就不知道了......
其实我们一般Redis缓存的比例都不是很高的,和机器学习训练集和测试集差不多,就二八开.所以咱们妥善考虑一下,指定好针对性的对策,一般来说问题不大(主要是我没遇到过问题大的)