小议缓存失效(穿透、雪崩和击穿)的风险及解决方案

可引起缓存失效的三大问题——穿透雪崩击穿:

一、缓存穿透

含义: 指查询一个缓存和数据库中均不存在的数据(极端的如负数或Integer.MAX_VALUE),由于缓存未命中,查询请求将会转到数据库,但数据库中也无此数据,且以往历次查询得到NULL结果的未被写入缓存,导致每次查询该数据的请求都会越过("穿透")缓存,落到数据库,使得缓存这道屏障形同虚设。
风险: 利用不存在的数据对数据库进行高并发查询,数据库感到瞬时压力过大,终因暗箭难防,寡不敌众,撒手寰,含恨而去。
解决方案: 将从数据库查询的NULL结果以适当形式(比如0)写入缓存,并设置较短的过期时间。

二、缓存雪崩

含义: 指在将数据写入缓存时,恰巧出现大量同批次数据的Key设置了相同的过期时间的情况,或者过期时间值比较单一,数据过期时间重合率高,导致大量数据的缓存在某一时刻同时失效(面积之大,势如雪崩),使得大批量请求落库。
风险: 孤军奋战的DB,势单力薄,终究无法顶住瞬间打来的大并发流量的突袭而被打崩,“溃不成”。
解决方案: 在设置失效时间时采用随机值,如1-50秒随机,这样每个缓存的过期时间的重复率就会降低,从而避免集体失效事件的发生率。

三、缓存击穿

含义: 一些访问热度较高的数据,会在某些时段被大批请求极端高并发地访问。有一种情形是,某一高热度数据恰巧在大批请求到来时失效,那么,这一大批查询请求,就会像枪林弹雨击穿贪官恶霸的脑壳一般,全都穿过缓存打到DB老巢,形成缓存击穿。
风险: 历尽沧桑的DB老巢,本就风雨飘摇,定然扛不住大流量的瞬间精准暴击而轰然崩塌。
解决方案:
1、加锁。对于大量并发请求,只放行其中一个请求去DB中查询,剩余的请求一律等待(自旋)。被放行的请求查询完毕之后立即释放锁,其它请求才能抢到锁。后续抢到锁的请求,仍要先去查缓存,而此时缓存中已有数据,便不会再到DB中查询,从而避免缓存击穿;
2、延长高热度数据的过期时间,或者采用自动续期机制,但对于电商类应用,最好设置高热数据的Key永不过期;
3、分散存放。将高热度数据分布式地存放于不同的缓存分片或缓存集群中。

猜你喜欢

转载自blog.csdn.net/shinyolive/article/details/113933182
今日推荐