redis生产使用问题【大型项目】

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. 数据静态化

总结：