当我们访问某个key时，这个key对应的数据在数据源并不存在，每次针对这个key的请求从缓存中都获取不到，那么这些请求都会压到数据源（DB），从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

当我们访问某个key的时候，此时会去redis缓存中查找，但是此时redis缓存中并不存在这个key，那么它就会去数据库中查找。而我们每次请求都是在查找这个key → redis缓存中没有 → DB中查找，反反复复就使得应用服务器压力变大、redis命中率降低，同时过多的非正常url请求也会造成数据库崩溃。

1.2 缓存穿透的解决方案

对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
设置可访问的名单（白名单）：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。
进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

2.缓存击穿

2.1 什么是缓存击穿？

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

当我们查询某个key对应的数据时，它是存在于redis中的，但是它过期了，也就是说无法从redis中获取这个数据了，那么此时会去数据库中查找（这是单一请求的时候）。如果这个key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。也就是说：大量并发请求都是如此，redis中缓存数据过期了，这些请求全部转到数据库中查找，这就会造成后端数据库崩溃。

2.2 缓存击穿的解决方啊

（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的存活时长，避免在高并发期间这些数据过期。

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

（3）使用锁：

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

3.缓存雪崩

3.1 什么是缓存雪崩？

缓存雪崩与缓存击穿的区别在于：缓存雪崩是针对很多key而言的缓存，而缓存击穿则是针对某一个key。

正常情况下，访问应该是下图这样：👇👇👇

缓存雪崩发生是说：当我们访问多个key对应的数据时，这些key在redis中都过期（无法获取）了，那么这些大量的高并发请求就会转到后端DB中去查找访问，进而造成了数据库的崩溃现象。

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

3.2 缓存雪崩的解决方案

构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）。
使用锁或队列：用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况。
设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

4.分布式锁

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁主流的实现方案：

1. 基于数据库实现分布式锁

2. 基于缓存（Redis等）

3. 基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

1. 性能：redis最高

2. 可靠性：zookeeper最高

这里，我们就基于redis实现分布式锁。

4.1 使用setnx + del实现分布式锁的添加与释放

对某个key进行上锁：setnx

对某个key进行解锁：del

下面的截图案例：首先redis中没有users这个key，我们使用 setnx 对这个key进行加锁操作，值为10；之后我们尝试再次setnx，可以看到返回值是0，说明此时不能再修改users的值，也就是说之前操作对users加了锁，其他人就无法操作users，只能等待释放users的锁，也就是del命令。这里del users释放了锁之后，就可以再次对users加锁操作了。

这里对应的Java代码就如下图所示。

@GetMapping("/testLock")
public void testLock(){
    //1获取锁，setne
    Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
    //2获取锁成功、查询num的值
    if(lock){
        Object value = redisTemplate.opsForValue().get("num");
        //2.1判断num为空return
        if(StringUtils.isEmpty(value)){
            return;
        }
        //2.2有值就转成成int
        int num = Integer.parseInt(value+"");
        //2.3把redis的num加1
        redisTemplate.opsForValue().set("num", ++num);
        //2.4释放锁，del
        redisTemplate.delete("lock");

    }else{
        //3获取锁失败、每隔0.1秒再获取
        try {
            Thread.sleep(100);
            testLock();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

4.2 分布式锁优化之设置锁的过期时间

上面的案例中，我们的确给users加了锁，加锁之后，其他客户端也无法再操作users。

但是这里应该会出现一个问题：setnx刚好获取到锁，此时当前获取到锁的这个服务器的业务逻辑出现了异常（造成了redis崩溃），这就会导致users的锁无法释放，而其他服务器此时仍然无法操作users。

解决方案：对需要上锁的key设置过期时间，到了过期时间，无论如何自动释放锁。

1. 首先想到通过expire设置过期时间（缺乏原子性：如果在setnx和expire之间出现异常，锁也无法释放）

2. 在set时指定过期时间（推荐），在上锁的同时，设置锁的过期时间。（setnx + setex）

这里我们使用 set users 10 nx ex 10 来对users上锁，上锁的同时设置它的过期时间为10s。

//1获取锁，setne
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111", 10, TimeUnit.SECONDS);

4.3 分布式锁优化之UUID防误删

上面设置锁的过期时间案例中，仍然存在一些问题。

场景：如果业务逻辑的执行时间是10s。执行流程如下

a的业务逻辑没执行完，此时已经执行了5秒，5秒后锁被自动释放。但是此时a服务器出现了卡顿情况（业务逻辑并未执行完），导致a服务器自动释放了锁。
在a释放锁之后，b和c服务器将会争夺锁，假设此时b获取到锁，执行它的业务逻辑，5秒后锁被自动释放。
在b执行的这5秒业务逻辑期间，a服务器又恢复正常了，那么它此时肯定要继续执行自己的业务逻辑，但是a发现此时锁被b占有了，而b正在执行业务逻辑，那么此时a就会手动释放b上的锁（因为a已经自动释放过一次锁了，无法自动，就只能手动释放）。

最终等于没锁的情况。

面对这样的场景问题，解决方案是：为锁设置一个唯一值（例如：uuid），释放锁之前获取这个值，判断要释放的锁是否是自己的锁。

    @GetMapping("/testLock")
    public void testLock(){
        String uuid = UUID.randomUUID().toString();
        //1获取锁，setne
        Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid,3, TimeUnit.SECONDS);
        //2获取锁成功、查询num的值
        if(lock){
            Object value = redisTemplate.opsForValue().get("num");
            //2.1判断num为空return
            if(StringUtils.isEmpty(value)){
                return;
            }
            //2.2有值就转成成int
            int num = Integer.parseInt(value+"");
            //2.3把redis的num加1
            redisTemplate.opsForValue().set("num", ++num);
            //2.4释放锁，del
            //判断比较uuid值是否一样
            String lockUuid = (String)redisTemplate.opsForValue().get("lock");
            if(lockUuid.equals(uuid)) {
                redisTemplate.delete("lock");
            }
        }else{
            //3获取锁失败、每隔0.1秒再获取
            try {
                Thread.sleep(100);
                testLock();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }

4.4 分布式锁优化之LUA脚本保证删除的原子性

经过了上面的案例：UUID防误删，它仍然存在一些问题。看如下描述：

此时有a、b两个操作，a先对users上了锁，执行它的业务逻辑，执行完毕之后，a执行释放锁操作，在这个期间发生了问题：首先比较uuid是否一样，比较完一样证明这是自己的锁，而正要释放删除锁的时候（此时还未删除），锁到达了过期时间、自动释放了。。。此时b就获取到了锁，执行b的业务逻辑。因为之前a的删除锁操作并未做完，所以此时a仍然会执行锁的删除操作，那么自然而然就把b上的锁给删除了。（疑问：a为何能删除b的锁呢？不是已经添加了uuid吗？这里注意：a在执行删除锁操作时，已经进行了uuid比较，比较结果是一样证明是自己的锁；那么b此时获取的这个锁就是a的锁，当然可以删！！！）

造成这种情况的原因就是：无法保证删除锁操作的原子性。

解决方案：👇👇👇

    @GetMapping("testLockLua")
    public void testLockLua() {
        //1 声明一个uuid ,将做为一个value 放入我们的key所对应的值中
        String uuid = UUID.randomUUID().toString();
        //2 定义一个锁：lua 脚本可以使用同一把锁，来实现删除！
        String skuId = "25"; // 访问skuId 为25号的商品 100008348542
        String locKey = "lock:" + skuId; // 锁住的是每个商品的数据

        // 3 获取锁
        Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);

        // 第一种： lock 与过期时间中间不写任何的代码。
        // redisTemplate.expire("lock",10, TimeUnit.SECONDS);//设置过期时间
        // 如果true
        if (lock) {
            // 执行的业务逻辑开始
            // 获取缓存中的num 数据
            Object value = redisTemplate.opsForValue().get("num");
            // 如果是空直接返回
            if (StringUtils.isEmpty(value)) {
                return;
            }
            // 不是空 如果说在这出现了异常！ 那么delete 就删除失败！ 也就是说锁永远存在！
            int num = Integer.parseInt(value + "");
            // 使num 每次+1 放入缓存
            redisTemplate.opsForValue().set("num", String.valueOf(++num));
            /*使用lua脚本来锁*/
            // 定义lua 脚本
            String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
            // 使用redis执行lua执行
            DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
            redisScript.setScriptText(script);
            // 设置一下返回值类型 为Long
            // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
            // 那么返回字符串与0 会有发生错误。
            redisScript.setResultType(Long.class);
            // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
            redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
        } else {
            // 其他线程等待
            try {
                // 睡眠
                Thread.sleep(1000);
                // 睡醒了之后，调用方法。
                testLockLua();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

以上是关于Redis——缓存穿透缓存击穿缓存雪崩分布式锁的主要内容，如果未能解决你的问题，请参考以下文章

Redis——缓存穿透缓存击穿缓存雪崩分布式锁

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

SpringBoot整合Redis以及缓存穿透缓存雪崩缓存击穿的理解如何添加锁解决缓存击穿问题？分布式情况下如何添加分布式锁

Redis05（缓存穿透，缓存击穿，缓存雪崩，分布式锁ACLIO多线程支持Cluster）

SpringBoot整合Redis以及缓存穿透缓存雪崩缓存击穿的理解分布式情况下如何添加分布式锁续篇

Redis缓存击穿，缓存穿透，缓存雪崩解决方案（附代码）