Redis(三)缓存击穿、缓存穿透、雪崩详解及解决办法

缓存穿透

用户想要查询一个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发·现也没有,于是本次查询失败。当用户很多的时候,缓存都没有命中(秒杀! ) ,于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透。

• 缓存空值，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存。

• 规范key的命名，并且统一缓存查询的入口，在入口处对key的命名格式进行检测，过滤掉不规范key的访问，这样可以过滤掉大部分的恶意攻击。如约定项目中Redis缓存key的前缀都是以"公司名_项目名_REDIS_"开头，不符合这个约定的key在一开始就过滤掉。

• 加锁 根据key从缓存中获取到的value为空时，先锁上，再去查DB将数据加载到缓存，若其它线程获取锁失败，则等待一段时间后重试，从而避免了大量请求直接打到DB。单机可以使用synchronized或ReentrantLock加锁，分布式环境需要加分布式锁，如Redis分布式锁。

• 布隆过滤器
  布隆过滤器是一种数据结构,对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力
  如果想判断某个元素是不是在一个集合里，一般做法是将集合中所有的元素保存起来，然后通过比较确定，比如HashMap。但是随着集合中元素的增加，数据量超大时，我们需要的存储空间也越来越大，甚至超过服务器内存，这时我们就不能再用HashMap等数据结构了。

  这时布隆过滤器就出场了，它的空间效率非常好，它是一个二进制向量，每一位存放的是0或1，初始时默认为0，长下面这样:
  当一个元素加入集合时，通过 K 个 Hash 函数将这个元素映射成 k 个值 ：K1、K2、K3…，把向量中下标为K1、K2、K3…的位置设置为1 。

  比如，元素X进来，将X作为参数，通过3个hash函数的计算，分别得到3个值：Hash1(X)=5；Hash2(X)=2；Hash3(X)=9；那么我们就将布隆过滤器中下标为5、2、9的位置分别置为1，如下：
  
  可以看出，布隆过滤器根本没有存放完整的数据，只是运用一系列随机映射函数计算出位置，然后填充二进制向量，所以它的空间效率非常好。

  有一个元素Y，怎么判断Y在布隆过滤器中是否存在呢？

  同样将Y作为参数，通过3个hash函数的计算，分别得到3个值，比如是：4/6/8，我们只要看下标为4/6/8的位置是不是都是1

  如果都是1，则元素Y可能存在于集合中，为什么说可能呢——hash碰撞，不同的两个元素，经过同样的hash函数，计算出来的值，从概率上来讲是有可能重复的。所以这也是布隆过滤器最大的缺点，存在误判率。

  如果不全是1，则元素Y肯定不存在。

  即：当它说某个 key 不存在时，key一定不存在；当它说某个 key 存在时，key 可能存在。

  布隆过滤器是怎样解决缓存穿透的？

  预先将所有缓存数据的key存放到布隆过滤器中，当一个查询请求过来的时候，先判断这个key在布隆过滤器中是否存在

  如果不存在，直接返回提示，都不用去查缓存更不用说DB了

  如果存在，则去查缓存，但我们知道布隆过滤器判断存在有一定的误判率，如果这个误判率针对业务场景是可被接受的 则可以忽略，另外我们在用Guava实现布隆过滤器的时候可以指定误判率不超过多少，可以指定一个被接受的值。再或者，因为布隆过滤器可以过滤掉绝大多数的恶意key，针对少部分的漏网之鱼，我们可以在缓存层面使用功能上面说过的缓存空值或加锁的方案

缓存击穿

这里需要注意和缓存击穿的区别,缓存击穿,是指一个key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

• 设置热点数据永不过期：从缓存层面来看,设置过期时间,所以不会出现热点key过期后产生的问题。

• 加锁：根据热点key从缓存中获取到的value为空时，先锁上，再去查DB将数据加载到缓存，若其它线程获取锁失败，则等待一段时间后重试，从而避免了大量请求直接打到DB。单机可以使用synchronized或ReentrantLock，分布式需要加分布式锁，如Redis分布式锁。【为了不阻塞对其他key的请求，此处可以用热点key来加锁】

缓存雪崩

缓存雪崩,是指在某一个时间段,缓存集中过期失效。Redis宕机是产生雪崩的原因之一,比如马上就要到双十一零点,一波商品时间比较集中的放入了缓存,假设缓存一个小时。那么到了凌晨一点钟的时候,这批商品的缓存就都过期了。而对这批商品的访问查询都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。
其实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩,一定是在某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。

• redis高可用：这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis ,这样一台挂掉之后其他的还可以继续工作,其实就是搭建的集群。(异地多活! )
• 限流降级：这个解决方案的思想是,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
• 数据预热：数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问一遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key ,设置不同的过期时间,让缓存失效的时间点尽量均匀。