一、缓存穿透

1. 问题描述

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源(数据库)，从而可能压垮数据源(数据库)。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库
image.png

2. 解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义

方案一：对空值缓存

如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟

方案二：设置可访问的名单（白名单）

使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问

方案三：采用布隆过滤器

1. 简介

具体可以参考：https://www.cnblogs.com/ysocean/p/12594982.html

  • 布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）
  • 布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，而缺点在于有一定的误识别率（false-positive，假阳性），亦即，它可能会把不是集合内的元素判定为存在于集合内，不过这样的概率相当小，在大部分的生产环境中是可以接受的
  • 将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

其原理比较简单，如下图所示，S集合中有n个元素，利用k个哈希函数，将S中的每个元素映射到一个长度为m的位（bit）数组B中不同的位置上，这些位置上的二进制数均置为1，如果待检测的元素经过这k个哈希函数的映射后，发现其k个位置上的二进制数不全是1，那么这个元素一定不在集合S中，反之，该元素可能是S中的某一个元素
image.png
image.png

布隆过滤器有一定误判率，和链表的长度有关，可以通过hash算法提高准确率

image.png

虽然不能保证key一定存在，但是可以保证key一定不存在 另外，布隆过滤器无法删除

2. 基本使用

导入相关的依赖包

  1. <dependency>
  2.     <groupId>com.google.guava</groupId>
  3.     <artifactId>guava</artifactId>
  4.     <version>29.0-jre</version>
  5. </dependency>

测试代码

public void testA2(){
    //1,创建bloom过滤器
    BloomFilter bloomFilter = BloomFilter.create(
            Funnels.stringFunnel(Charset.forName("utf-8")), //定义key的类型
            10000, //用于判断的数据链大小
            0.1 //期望的误差
    );
    //2，添加预设值
    for (int i=0;i<10000;i++){
        bloomFilter.put(String.valueOf(i));
    }
    //3，通过错误率
    int count=0;
    for (int i=0;i<10000;i++){
        boolean isExist = bloomFilter.mightContain("xxx"+i);
        if(isExist){
            count++;
        }
    }
    System.out.println("错误率是:"+count/10000.0+"%");
}

方案四：进行实时监控

当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

二、缓存击穿

1. 问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮
image.png

2. 解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题

方案一：预先设置热门数据

在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

方案二：实时调整

现场监控哪些数据热门，实时调整key的过期时长

方案三：使用锁机制

  • 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
  • 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key
  • 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
  • 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法

image.png

三、缓存雪崩

1. 问题描述

  • key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮
  • 缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key正常访问

image.png
缓存失效瞬间
image.png

2. 解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！

方案一：构建多级缓存架构

nginx缓存 + redis缓存 +其他缓存（ehcache等）

方案二：使用锁或队列

用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

方案三：设置过期标志更新缓存

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存

方案四：将缓存失效时间分散开

比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件