Redis-缓存穿透，缓存击穿，缓存雪崩

缓存穿透

缓存穿透是指恶意或异常的查询请求导致缓存系统无法命中缓存，每次请求都要查询数据库或其他存储后端，导致数据库或存储系统压力过大的问题
可能造成的影响：数据库负载增加：频繁查询不存在的数据会导致数据库负载迅速增加，可能导致数据库崩溃或响应变得非常缓慢。

举一个例子：

一个get请求：api/news/getByid/2
通过这个id查询，我们后端会先去redis中查看是否有缓存，如果有的话直接从redis中返回就好了，如果没有则去查数据库，如果数据库中有的话，则缓存该数据并且返回

在我们实际上的请求中，有可能会出现查询不存在的id的情况，在这种情况下，我们redis查不到数据，导致大量的请求需要进行数据库查询操作，可能会造成数据库宕机。

处理方案

解决方案1 缓存空数据

缓存空数据，查询返回的数据为空，我们后端仍然把这个空结果进行缓存
优点：思路比较简单
缺点：比较消耗内存，可能发生不一致的问题

解决方案2 布隆过滤器

从上图中看，就好像一个净水器一样哈哈，作用其实有点类似

那么到底是怎么实现过滤的呢，其实底层是通过bitmap来实现的，而bitmap又是一个以bit为单位的数组，数组中每个位置只能存储二进制数0或1，例如我们传入一个数据id=1，那么布隆过滤器就会通过几个hash函数算出相应的值，如下图，传入id=1，通过hash1得到值为1，通过hash2得到值为3，通过hash3得到值为7，那么相应位置值都改为1，下次再传入数据id=1过来，我们只需要判断1，3，7这三个位置是否为1，即可判断该数据是否是空数据，当然布隆过滤器也是需要提前预热的。

缺点：实现比较复杂，存在误判
优点：内存占用比较少，没有多余的key
讲一下上面提到的误判：
在上图的前提下，如果此时又传入一个id=7，通过三个hash函数计算出来的值分别为，7，11，18。那么此时bitmap中有5个位置为1，分别为1，3，7，11，18，然而此时有一个空数据id=10，它通过hash函数计算出来的值分别为3，7，18，那么此时布隆过滤器会认为该数据不是空数据，产生一个误判的问题。

缓存击穿

缓存击穿是给某一个key设置了过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB给压垮

举一个例子：

用白话来讲其实就是在设置redis的时候，我们设置了热点数据以及热点数据过期时间，但是等到热点数据的过期时间到了之后，该热点数据还是有多请求打过来，那么此时redis中不存在此热点数据的缓存了，就会将这些请求全部打在DB上，此时就会出现DB还来不及重建redis就被打死的情况

处理方案

解决方案 1 互斥锁

这个流程其实很好懂，当线程1进来查询缓存发现未命中后，加一把互斥锁，然后才查询数据库重建redis缓存，如果在重建还未完成的时候有别的线程进来想要查询数据就会被拦截了，一直要等到线程1将数据重新写入redis然后释放锁之后才能够拿到。
优点：强一致性
缺点：性能差

解决方案2 逻辑过期

逻辑过期，意味着永不过期。缓存击穿问题产生的原因是某个热点key过期了，请求都打到数据库了，造成数据库压力过大。因此我们可以提前准备一个不过期的热点key ，不设置它的过期时间，将这个key保存到redis中，这样理论上总能命中redis。那是怎么判断这个key逻辑上过期了？答案是这个key的value存储一个过期时间，我们判断这个key是否过期的依据，就是这个key的value保存的过期时间。

优点：高可用，性能高
缺点：不能保证数据的绝对一致，因为无论此数据是否过期，它都会直接就返回当前的数据

缓存雪崩

缓存雪崩是指在同一个时段大量缓存的key同时失效或者redis服务宕机了，导致大量的请求全部打到数据库

处理方案

解决方案 1 给不同的key的过期时间设置添加一个随机值，降低同一个时段大量key同时过期的概率

解决方案 2 如果redis服务宕机，可以利用redis一些高可用的方案 比如哨兵模式，集群模式

解决方案 3 给缓存业务添加降级限流策略 可以利用ngxin或者getway

解决方案 4 给业务添加多级缓存 Guava或者caffeine为一级缓存，redis为二级缓存