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

1 我们是如何利用缓存的？

有用户请求过来，先查缓存，如果缓存中有数据，直接返回给用户。如果不存在，去数据库查找，如果找得到，则写入缓存供下次查询，并且返回。如果数据库中也不存在，返回失败。
流程如下：

2 什么是缓存穿透？

两种特殊情况：

• 用户请求的id在缓存中不存在
• 恶意用户伪造不存在的id发起请求

这两种情况的结果就是，每次请求都要去查询一次数据库。

每次走的都是红线，缓存根本没起作用，好像被穿透了一样。请求过多可能会让数据库挂掉。

2.1 策略1 ：校验参数

对用户的id做校验，比如合法id为wx***** 以wx开头 那么对于其他开头的直接校验失败，拦截查询请求。

2.2 策略2 ：布隆过滤器

底层：

• 布隆过滤器使用的是bit数组存储数据，默认为1

方法：

• 把数据库中已存在的key，进行hash运算，每个key都算出多个位置，将这些位置的值设置为1
  有key请求过来，hash计算，如果和应该赋值1的位置吻合，说明存在，则去缓存查找。
  如果有0，说明不存在，拒绝请求。
  
  存在的问题：
• 存在误判（hash冲突，某个key本来不存在，但是hash后与其他存在的key得到的位置一样，导致误认为一样。解决：多几次hash，比如算出来5个位置，都重复的可能性就低了）
• 数据更新后的一致性问题。（比如新增了一个用户，还没来得及更新到布隆过滤器，就有人来查询它，请求被拒绝）

2.3 策略3 ：缓存空值

当某个id在缓存中查不到，数据库也查不到，就把该id缓存起来，不过在缓存中保存的是空值。（这个方法比较占内存）

3 什么是缓存击穿？

我们在访问热点数据时，比如在商城购买某个爆款商品。一般这种爆款会存在缓存中，但是某个时刻，缓存过期了。导致大量用户对于该商品的查询，都到了数据库中，瞬间数据库压力过大，直接挂掉。
流程如下：

3.1 策略1 ：自动续期

缓存击穿时由于key过期导致，那么在key要过期前给他自动续期。
用job来给指定的key自动续期，每隔二十分钟执行一次，自动续期30分钟。

3.2 策略2 ：缓存永不失效

对于这些热门商品，不用设置过期时间，热门商品比较少，在缓存中也不会太占内存。让其永久有效。
比如秒杀商品，活动前先查询出商品，让他生成缓存。提前做预热。活动结束，直接手动删除即可。

3.3 策略 3 ：加锁

数据库压力大是因为同一时刻太多的请求访问了数据库，加锁限制同一时刻只有一个请求才能访问某商品。还有就是 这些key一般重建的业务都比较复杂，建立缓存速度比较慢。线程1 发现没有，去创建 线程2 发现没有也去创建 就会更拥堵 只需要互斥锁 来保证只有一个去创建缓存 不至于拥堵

4 什么是缓存雪崩？

缓存雪崩是缓存击穿的升级版

• 多个热门的key同时生效，大量对于热门商品的查询都来了，但是缓存没有，瞬时都去数据库查询。
• 某个缓存服务器宕机了，导致它缓存的东西都没了，总之就是大量缓存的不可用。
  

4.1 策略 1 ：过期时间加随机数

加随机数的目的就是让这些key不要同时过期

实际过期时间 = 过期时间 + 1~60秒的随机数

有了随机数的存在，也就不会出现太多相同时间过期的key

4.2 策略 2 ：高可用

针对缓存服务器宕机的情况，前期系统架构的时候，可以做一些高可用架构
比如redis中的哨兵模式、集群模式，避免出现单个结点故障导致整个redis服务不可用的情况。

使用哨兵模式之后，当某个master服务下线时，自动将该master下的某个slave服务升级为master服务，替代已下线的master服务继续处理请求

4.3 策略 3 ：服务降级

如果做了高可用架构，redis服务还是挂了怎么办？
服务降级，配置一些默认的兜底数据。
程序中有个全局开关，比如有10个请求在最近一分钟内，从redis中获取数据失败，则全局开关打开。后面的新请求，就直接从配置中心中获取默认的数据。

当然，还需要有个job，每隔一定时间去从redis中获取数据，如果在最近一分钟内可以获取到两次数据（这个参数可以自己定），则把全局开关关闭。后面来的请求，又可以正常从redis中获取数据了。
参考博客来源