前言

Redis的缓存穿透、缓存雪崩、缓存击穿是啥?各位看官进来看看

面试官考我Redis中的缓存穿透、缓存雪崩和缓存击穿

缓存穿透

缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。

缓存穿透产生的原因是什么？

用户请求的数据在缓存中和数据库中都不存在，不断发起这样的请求，给数据库带来巨大压力.

客户端恶意疯狂访问打入Redis没有命中直接去数据库查询也没有则返回Null 那么下次访问还是这样子.

那么常见的解决方案有两种

• 缓存空对象
  • 优点：实现简单，维护方便
  • 缺点：
    • 额外的内存消耗
    • 可能造成短期的不一致
• 布隆过滤
  • 优点：内存占用较少，没有多余key
  • 缺点：
    • 实现复杂
    • 存在误判可能

缓存空对象

**缓存空对象思路分析：**当我们客户端访问不存在的数据时，先请求redis，但是此时redis中没有数据，此时会访问到数据库，但是数据库中也没有数据，这个数据穿透了缓存，直击数据库，我们都知道数据库能够承载的并发不如redis这么高，如果大量的请求同时过来访问这种不存在的数据，这些请求就都会访问到数据库，简单的解决方案就是哪怕这个数据在数据库中也不存在，我们也把这个数据存入到redis中去，这样，下次用户过来访问这个不存在的数据，那么在redis中也能找到这个数据就不会进入到缓存了

布隆过滤器

**布隆过滤：**布隆过滤器其实采用的是哈希思想来解决这个问题，通过一个庞大的二进制数组，走哈希思想去判断当前这个要查询的这个数据是否存在，如果布隆过滤器判断存在，则放行，这个请求会去访问redis，哪怕此时redis中的数据过期了，但是数据库中一定存在这个数据，在数据库中查询出来这个数据后，再将其放入到redis中,假设布隆过滤器判断这个数据不存在，则直接返回

这种方式优点在于节约内存空间，存在误判，误判原因在于：布隆过滤器走的是哈希思想，只要哈希思想，就可能存在哈希冲突

不常见的是思考类的解决方案:

• 缓存null值
• 布隆过滤
• 增强id的复杂度，避免被猜测id规律
• 做好数据的基础格式校验
• 加强用户权限校验
• 做好热点参数的限流

缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

例子:

我有一个商品表里面有几百万的商品数据因之前已经预热缓存到Redis当中并且设置了过期时间,我滴妈🈶️一天早上时间全部过期导致大量用户的同时访问导致数据库请求压力增大,被领导骂惨了(只是例子我没有干过)

那么字面意思解决方案：

• 给不同的Key的TTL添加随机值
• 利用Redis集群提高服务的可用性
• 给缓存业务添加降级限流策略
• 给业务添加多级缓存

缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。(我感觉这种情况小的可怜,咱们就理解理解面试的时候吹起来就行)

常见的解决方案有两种：

• 互斥锁
• 逻辑过期

逻辑分析：假设线程1在查询缓存之后，本来应该去查询数据库，然后把这个数据重新加载到缓存的，此时只要线程1走完这个逻辑，其他线程就都能从缓存中加载这些数据了，但是假设在线程1没有走完的时候，后续的线程2，线程3，线程4同时过来访问当前这个方法， 那么这些线程都不能从缓存中查询到数据，那么他们就会同一时刻来访问查询缓存，都没查到，接着同一时间去访问数据库，同时的去执行数据库代码，对数据库访问压力过大

案例

互斥锁方式解决缓存击穿

案例: 我这里有个测试Demo里面有一个接口是查询商铺详细信息的

需求: 修改根据id查询商铺的业务，基于互斥锁方式来解决缓存击穿问题

认识 SETNX 锁

在Redis中，SETNX是一个用于设置键的值的命令，但只有在键不存在时才会设置成功。如果键已经存在，那么SETNX命令不会执行任何操作。这个命令的名称代表"Set if Not eXists"，它通常用于创建分布式锁或确保某个操作在同一时间只能被一个客户端执行。

以下是一个使用SETNX的简单案例：

假设你正在开发一个多用户的在线商店，并且你需要确保每个用户只能领取一次优惠券。你可以使用SETNX来实现这个需求。

首先，你可以为每个优惠券创建一个唯一的标识符，比如优惠券的编号。然后，你可以使用以下Redis命令来检查并设置用户是否已经领取了该优惠券：

6392:0>setnx yby6Lock '我是锁参数随便啥都可以'
"1"
6392:0>setnx yby6Lock '我是第二个人来拿锁看看能不能拿到'
"0"
6392:0>

在上面的命令中，yby6Lock是一个键，用于表示用户123是否已经领取了优惠券42。如果用户123之前没有领取这张优惠券，SETNX命令将会设置键的值为1（或任何你指定的值），并返回1表示设置成功。如果用户123之前已经领取了这张优惠券，SETNX命令不会执行任何操作，并返回0表示设置失败。

通过检查SETNX命令的返回值，你可以确定用户是否成功领取了优惠券，以确保每个用户只领取一次。这种方法可以避免多个用户同时领取相同的优惠券，确保了领取的唯一性。

释放锁

6392:0>setnx yby6Lock '我是锁参数随便啥都可以'
"1"
6392:0>setnx yby6Lock '我是第二个人来拿锁看看能不能拿到'
"0"
6392:0>del yby6Lock '我释放'
"1"
6392:0>setnx yby6Lock '我是第二个人来拿锁看看能不能拿到'
"1"
6392:0>setnx yby6Lock '我是第三个人来拿锁看看能不能拿到'
"0"
6392:0>

锁流程解析:

1. setnx yby6Lock '我是锁参数随便啥都可以'
   • 这个命令尝试在Redis中设置一个键为yby6Lock的值，但仅当该键不存在时才设置。如果成功设置，它会返回整数1，表示锁已成功获取。
2. setnx yby6Lock '我是第二个人来拿锁看看能不能拿到'
   • 这个命令尝试再次设置键yby6Lock的值，但这次由于前一个命令已经成功设置了锁，所以这次会失败。因此，它返回整数0，表示无法获取锁。
3. del yby6Lock '我释放'
   • 这个命令用于删除键yby6Lock。在分布式锁中，释放锁是在客户端完成对共享资源的工作后应执行的操作。这个命令返回整数1，表示成功删除了键。
4. setnx yby6Lock '我是第二个人来拿锁看看能不能拿到'
   • 在释放锁后，这个命令再次尝试设置键yby6Lock的值，这次它成功了，因为前面的命令已经删除了该键。所以它返回整数1，表示成功获取锁。
5. setnx yby6Lock '我是第三个人来拿锁看看能不能拿到'
   • 这个命令是另一个客户端尝试获取锁的示例，但由于前一个命令已经成功获取了锁，所以这次也会失败。它返回整数0，表示无法获取锁。

客户端首先尝试设置一个键，如果成功设置，它就拥有了锁。在完成工作后，客户端可以使用DEL命令来释放锁，以便其他客户端可以获取它。如果其他客户端尝试获取已经被锁定的资源，它们将不会成功。这可以用于确保在分布式系统中对共享资源的安全访问。

代码展示

案例兄弟们可以自己搭建一个CRUD的SpringBoot+Redis+Mysql+Mybatis的Demo

定义方法

/**
* 互斥锁
* @param keyPrefix 锁前缀
* @param id 唯一ID
* @param type 数据类型
* @param dbFallback  函数接口查询接口
* @param time 锁过期时间
* @param unit 时间类型
* @return {@link R}
*/
public <R, ID> R queryWithMutex(
        String keyPrefix, ID id, Class<R> type, Function<ID, R> dbFallback, Long time, TimeUnit unit) {

 // .....互斥锁 业务代码
        
}

1. 从redis查询商铺缓存

String key = keyPrefix + id;
String shopJson = stringRedisTemplate.opsForValue().get(key);

2. 判断是否存在

// 2.判断是否存在
if (StrUtil.isNotBlank(shopJson)) {
  // 3.存在，直接返回
  return JSONUtil.toBean(shopJson, type);
}
// 判断命中的是否是空值
if (shopJson != null) {
  // 返回一个错误信息
  return null;
}

3. 实现缓存构建 获取互斥锁 setnx (分布式锁)

定义锁名称 “yby6Lock” + 你表当中的主键ID;

String lockKey = "yby6Lock" + id;
// 定义查询到的缓存数据
R r = null;
try {
  boolean isLock = tryLock(lockKey);
  // 4.2.判断是否获取成功
  if (!isLock) {
    // 4.3.获取锁失败，休眠并重试
    Thread.sleep(50);
    // 递归重新调用去获取锁
    return queryWithMutex(keyPrefix, id, type, dbFallback, time, unit);
  }
  // 4.4.获取锁成功，根据id查询数据库
  r = dbFallback.apply(id);
  // 5.不存在，返回错误
  if (r == null) {
    // 将空值写入redis
    stringRedisTemplate.opsForValue().set(key, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
    // 返回错误信息
    return null;
  }
  // 6.存在，写入redis
  this.set(key, r, time, unit);
} catch (InterruptedException e) {
  throw new RuntimeException(e);
}finally {
  // 7.释放锁
  unlock(lockKey);
}
// 8.返回缓存数据
return r;

测试互斥锁(分布式锁)

我使用api测试工具

先查询一下是否可访问

互斥锁成功、实际上访问我们数据库就一次其他的都走Redis缓存查询

最后

本期结束咱们下次再见👋~

🌊 关注我不迷路，如果本篇文章对你有所帮助，或者你有什么疑问，欢迎在评论区留言，我一般看到都会回复的。大家点赞支持一下哟~ 💗