1. 中小项目:最常见用法
读接口:先读redis,redis没有,读DB,把db的数据同时设置到redis
写接口:先写db,更新redis
2. 中大项目:
因为数据量太大,不能全放redis,所以设置redis的失效时间
引发问题:
缓存击穿:由于很多商品可能是批量上架,失效时间默认设置的是一样,这样可能大批商品redis数据会同时失效了,这样短时间内大量访问到了DB,
解决方法:1. 商品设置时间不一样+随机数
2. 每次读延期/续命
3. 热点数据,定时任务去set到redis
缓存穿透:情况1. 热点数据,后台运营不小心把db和redis数据都删除了
情况2. 黑客知道接口的参数规则,比如userId+1,大量并发走这个参数和接口,而对应的这个参数redis和db都没有,这样大量并发攻击请求就穿透到了DB
解决方法:1. 如发现db没有,redis就set一个空值(或者"{}")同时设置失效时间和续命(随机+短),这样同一个参数只会走一次db
2. 布隆过滤器。或者查询参数key的过滤器,先判断key是否合法,相关加密货sign规则
突发性热点缓存重建:情况:冷门商品(redis没)突然被主播搞为热门商品,大量请求就到了db
解决方法:1. 给查db的mapper代码,加锁,synchronized(this){},this,可以改为商品id,或者用分布式锁。下图是redisson分布式锁
简称DCL,双层检测锁:双层redis查询+1检测锁(图代码上层还有原本的一次redis查询),下图是用synchronized同步锁
雪崩:很多key同时失效了,跟穿透不一样的是,穿透是1各key突然没了,或失效了。解决方法跟穿透类似
降级:看下图,解决方法:1本地内存的缓存解决,2返回默认值,3. 数据静态化
总结: