缓存穿透
什么是缓存穿透？
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库。
解决方案（2种）
（1）缓存空对象
简单的来说，就是请求之后，发现数据不存在，就将null值打入Redis中。
优点：
- 实现简单，维护方便
缺点：
- 额外的内存消耗
- 可能造成短期的不一致
分析：
当请求第一次来时，数据库中没有该数据，数据库向Redis写入一个null；此时正好数据库中被插入了该数据，又有一个请求来访问，但是刚刚向Redis中插入的null来没有过期，就出现了不一致（该请求从Redis拿到的结果就是null，而数据库中其实是有实际数据的）
当然我们也有许多的解决办法，例如：将TTL的时间设置的足够短；每次向数据库新增数据的时候主动将其插入缓存中去覆盖那个null。
（2）布隆过滤
在客户端与Redis之间加了一个布隆过滤器，对于请求进行过滤。
布隆过滤器的大致的原理：布隆过滤器中存放二进制位。数据库的数据通过hash算法计算其hash值并存放到布隆过滤器中，之后判断数据是否存在的时候，就是判断该hash值是0还是1。
但是这个玩意是一种概率上的统计，当其判断不存在的时候就一定是不存在；当其判断存在的时候就不一定存在。所以有一定的穿透风险！！！
优点：
- 内存占用较少，没有多余key
缺点：
- 实现复杂
- 存在误判可能
综上所述
我们可以两种方案一起用，这样子最为保险。据统计使用布隆过滤器一般可以避免90%的无效请求。但是黑马程序员这里的视频是使用方案一（缓存空对象）。
代码实现
思路图解
显然我们在这里只要做两件事：
- 当查询数据在数据库中不存在时，将空值写入 redis
- 判断缓存是否命中后，再加一个判断是否为空值
@Override
public Result queryById(Long id) {
// 从redis查询商铺缓存
String key = CACHE_SHOP_KEY + id;
String shopJson = stringRedisTemplate.opsForValue().get(key);
// 判断是否存在
if (StrUtil.isNotBlank(shopJson)) {
// 存在，直接返回
Shop shop = JSONUtil.toBean(shopJson, Shop.class);
return Result.ok(shop);
}
// 1.判断空值
if (shopJson != null) {
// 返回一个错误信息
return Result.fail("店铺不存在！");
}
// 不存在，根据id查询数据库
Shop shop = getById(id);
// 不存在，返回错误
if (shop == null) {
// 2.防止穿透问题，将空值写入redis!!!
stringRedisTemplate.opsForValue().set(key,"",CACHE_NULL_TTL,TimeUnit.MINUTES);
return Result.fail("店铺不存在！");
}
// 存在，写入Redis
// 把shop转换成为JSON形式写入Redis
// 同时添加超时时间
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), CACHE_SHOP_TTL, TimeUnit.MINUTES);
return Result.ok(shop);
}运行测试
我们可以查看后台接口数据
扩展
上述所提到的两种方案其实都是被动的，（即缓存穿透已经发生了）
在此之前我们应该先行避免这种现象的发生。如何避免？？？
- 我们可以增加 id 设计时的复杂度，避免被本人猜到 id 的规律
- 做好基础数据格式校验（将不符合我们定义规范的 id 先行剔除）
- 加强用户权限的校验
- **做好限流（SpringCloud~~~）
缓存雪崩
什么是缓存雪崩？
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。情况大致如下图所示：
解决方案（4种）
（1）给不同的Key的TTL添加随机值（推荐）
操作简单，当我们在做缓存预热的时候，就有可能在同一时间批量插入大量的数据，那么如果它们的TTL都一样的话就可能出现大量key同时过期的情况！！！所以我们需要在设置过期时间TTL的时候，定义一个范围，追加该范围内的一个随机数。
（2）利用Redis集群提高服务的可用性
使用集群提高可靠性，后续讲解~~~之后写了会在这里贴上链接。
（3）给缓存业务添加降级限流策略
也是后续的微服务的知识~~~SpringCloud中有提！！！
（4）给业务添加多级缓存
请求到达浏览器，nginx可以做缓存，未命中找Redis，再未命中找JVM，最后到数据库......
SpringCloud中有多级缓存的实现方案，Redis后期也会提到，之后也会更新。
缓存击穿
什么是缓存击穿？
缓存雪崩是因为大量的key同时过期所导致的问题，而缓存击穿则是部分key过期导致的严重后果。
为什么大量key过期会产生问题而少量的key也会有问题呢？？？
这是因为这一部分的key不简单！！！
缓存击穿问题也叫热点Key问题，就是⼀个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。
具体情况如下图所示：
上述：此时假设该热点key的TTL时间到（失效了），则查询缓存未命中，会继续查询数据库，并进行缓存重建工作。但是由于查询SQL逻辑比较复杂、重建缓存的时间较久，并且该key又是热点key，短时间内有大量的线程对其进行访问，所以请求会直接 “打到” 数据库中，数据库就有可能崩掉！！！
解决方案（2种）
（1）互斥锁
简单的来说就是，并不是所有的线程都有 “ 资格 ” 去访问数据库，只有持有锁的线程才可以对其进行操作。
不过该操作有一个很明显的问题，就是会出现相互等待的情况。
（2）逻辑过期
不设置TTL，之前所说导致缓存击穿的原因就是该key的TTL到期了，所以我们在这就不设置TTL了，而是使用一个字段例如：expire表示过期时间（逻辑上的）。当我们想让它 “ 过期 ” 的时候，我们可以直接手动将其删除（热点key，即只是在一段时间内，其被访问的频次很高）。
互斥锁与逻辑过期的对比分析
