什么是Redis缓存穿透，缓存击穿，缓存雪崩

常规代码操作：

1.缓存穿透-  key非法

问题场景：你系统有一个查询商品详情接口，参数是商品id，你的代码逻辑是，先根据商品id查redis，如果redis查不到，就往数据库DB查。攻击者故意伪造n个非法不存在的商品id，同时高并发访问这个接口，那么redis肯定查不到，那么这种请求全部达到了DB，所以这里就造成了大量瞬间db操作，很有可能会使数据库崩溃cpu达到100%，影响整个系统的使用。

当然以上还有一种正常业务情况，运营人员误操作把相关热点商品下架了，导致redis的数据不存了，大批量合法正常用户请求也可能会走到DB。这种情况，要做业务和技术的规避，以及相关的数据监控手段

解决办法：

1. 接口新增token参数校验，可采用jwt方案

2. 当数据库查不到的时候，redis存一个null值（比如是一个null的空字符串），并设置有效时间，这样之后的请求会走到redis了，但是这里不能解决攻击者发送不同的非法key的攻击

3. 降级：业务牺牲，redis查不到，就是不查DB，以redis和基准，通过完善的数据同步，尽量保证redis和mysql的数据一致

4. 针对同一IP访问本接口做限流处理，比如sentinel

5. 商品id的判断：布隆过滤器

2.缓存击穿（单个key在redis失效了，瞬间大量请求）

缓存击穿是指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db

解决方案：

1.预先设置热门数据，提前存入缓存

2.实时监控热门数据，调整key过期时长

3.二级缓存（本地缓存ehcache）:对于热点数据进行二级缓存，并对于不同级别的缓存设定不同的失效时间。

4.设置分布式锁（A线程判断缓存失效后，先开锁，让其他线程等着，这个线程把数据库set到redis，然后之后的线程就全走redis了）

3.缓存雪崩（多个key同时失效，大量请求达到DB）

大量的应用请求无法在Redis缓存中进行处理，紧接着应用将大量请求发送到数据库层，导致数据库层的压力激增

击穿与雪崩的区别即在于击穿是对于特定的热点数据来说，而雪崩是全部数据。

原因一：缓存中有大量Key同时过期，导致大量请求无法得到处理，大量数据需要回源数据库

1. 差异化设置过期时间
差异化缓存过期时间，不要让大量的 Key 在同一时间过期。比如，在初始化缓存的时候，给这些数据的过期时间增加一个较小的随机数，这样一来不同数据的过期时间有所差别又差别不大，即避免了大量数据同时过期又能保证这些数据在相近的时间失效

2. 服务降级
允许核心业务访问数据库，非核心业务直接返回预定义的信息

3. 不设置过期时间 + 定时任务把数据库同步到redis
初始化缓存数据的时候设置缓存永不过期，然后启动一个后台线程 30 秒一次定时把所有数据更新到缓存，而且通过适当的休眠，控制从数据库更新数据的频率，降低数据库压力。
 

原因二：Redis实例发生故障宕机，无法处理请求，就会导致大量请求积压到数据库层 

1. 服务熔断
暂停业务应用对缓存服务的访问，从而降低对数据库的压力

2. 请求限流
控制每秒进入应用程序的请求数，避免过多的请求被发到数据库

3. Redis构建高可靠集群
通过主从节点的方式构建Redis高可靠集群。可以保证在Redis主节点故障宕机时，从节点切换到主节点，继续提供服务，避免由于缓存实例宕机导致缓存雪崩