2.6. 缓存穿透问题的解决思路
- 缓存穿透：缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远都不会生效（只有数据库查到了，才会让redis缓存，但现在的问题是查不到），会频繁的去访问数据库。
- 常见的结局方案有两种
-
- 缓存空对象
-
-
- 优点：实现简单，维护方便
- 缺点：额外的内存消耗，可能造成短期的不一致
-
-
- 布隆过滤
-
-
- 优点：节省内存占用，没有多余的key
- 缺点：实现复杂，可能存在误判
-
- 缓存空对象思路分析：
-
- 当客户端访问不存在的数据时，会先请求redis，但是此时redis中也没有数据，就会直接访问数据库
- 但是数据库里也没有数据，那么这个数据就穿透了缓存，直击数据库。但是数据库能承载的并发不如redis这么高，所以如果大量的请求同时都来访问这个不存在的数据，那么这些请求就会访问到数据库。
- 简单的解决方案就是哪怕这个数据在数据库里不存在，我们也把这个这个数据存在redis中去（这就是为啥说会有额外的内存消耗），这样下次用户过来访问这个不存在的数据时，redis缓存中也能找到这个数据，不用去查数据库。
- 可能造成的短期不一致是指在空对象的存活期间，我们更新了数据库，把这个空对象变成了正常的可以访问的数据，但由于空对象的TTL还没过，所以当用户来查询的时候，查询到的还是空对象，等TTL过了之后，才能访问到正确的数据，不过这种情况很少见罢了。
- 布隆过滤思路分析：
-
- 布隆过滤器其实采用的是哈希思想来解决这个问题，通过一个庞大的二进制数组，根据哈希思想去判断当前这个要查询的数据是否存在。
-
-
- 如果布隆过滤器判断存在，则放行，这个请求会去访问redis，哪怕此时redis中的数据过期了，但是数据库里一定会存在这个数据，从数据库中查询到数据之后，再将其放到redis中。
- 如果布隆过滤器判断这个数据不存在，则直接返回。这种思想的优点在于节约内存空间，但存在误判，误判的原因在于：布隆过滤器使用的是哈希思想，只要是哈希思想，都可能存在哈希冲突
-
2.6.1. 编码解决商品查询的缓存穿透问题
- 核心思路如下
- 在原来的逻辑中，我们如果发现这个数据在MySQL中不存在，就直接返回一个错误信息了，但是这样存在缓存穿透问题
- 现在的逻辑是：如果这个数据不存在，将这个数据写入到Redis中，并且将value设置为空字符串，然后设置一个较短的TTL，返回错误信息。当再次发起查询时，先去Redis中判断value是否为空字符串，如果是空字符串，则说明是刚刚我们存的不存在的数据，直接返回错误信息
@Override
public Result queryById(Long id) {
String shopKey = RedisConstants.CACHE_SHOP_KEY + id;
//先从Redis中查询
String shopJson = redisTemplate.opsForValue().get(shopKey).toString();
//如果不为空，则转换为shop对象，首先检查字符串 shopJson 是否为 null，然后再检查是否为空字符串
if(StrUtil.isNotBlank(shopJson)){
Shop shop = JSONUtil.toBean(shopJson, Shop.class);
return Result.ok(shop);
}
//如果查询到的是空字符串，则说明是缓存的空数据，只是检查 shopJson 是否为 null。
if(shopJson != null){
return Result.fail("店铺不存在！！！");
}
//否则去数据库查
Shop shop = getById(id);
//查不到，将空字符串放入 Redis
if(shop == null){
//设置存在时间 2 分钟
redisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, "",RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
return Result.fail("店铺不存在！！！");
}
//查到了转为 JSON字符串
String jsonStr = JSONUtil.toJsonStr(shop);
//存入 Redis
redisTemplate.opsForValue().set(shopKey, jsonStr, RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
return Result.ok(shop);
}小结：
- 缓存穿透产生的原因是什么？
-
- 用户请求的数据在缓存中和在数据库中都不存在，不断发起这样的请求，会给数据库带来巨大压力
- 缓存产投的解决方案有哪些？
-
- 缓存null值
- 布隆过滤
- 增强id复杂度，避免被猜测id规律（可以采用雪花算法）
- 做好数据的基础格式校验
- 加强用户权限校验
- 做好热点参数的限流
2.7. 缓存雪崩问题及解决思路
- 缓存雪崩是指在同一时间段，大量缓存的key同时失效，或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力
- 解决方案
-
- 给不同的Key的TTL添加随机值，让其在不同时间段分批失效
- 利用Redis集群提高服务的可用性（使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控，在主节点出现故障的情况下，能将从节点中的一个升级为主节点，进行故障转义，保证系统的可用性。 ）
- 给缓存业务添加降级限流策略
- 给业务添加多级缓存（浏览器访问静态资源时，优先读取浏览器本地缓存；访问非静态资源（ajax查询数据）时，访问服务端；请求到达Nginx后，优先读取Nginx本地缓存；如果Nginx本地缓存未命中，则去直接查询Redis（不经过Tomcat）；如果Redis查询未命中，则查询Tomcat；请求进入Tomcat后，优先查询JVM进程缓存；如果JVM进程缓存未命中，则查询数据库）
2.8. 缓存击穿问题及解决思路
- 缓存击穿也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，那么无数请求访问就会在瞬间给数据库带来巨大的冲击
- 举个不太恰当的例子：一件秒杀中的商品的key突然失效了，大家都在疯狂抢购，那么这个瞬间就会有无数的请求访问去直接抵达数据库，从而造成缓存击穿。
- 假设线程1在查询缓存之后未命中，本来应该去查询数据库，重建缓存数据，完成这些之后，其他线程也就能从缓存中加载这些数据了。但是在线程1还未执行完毕时，又进来了线程2、3、4同时来访问当前方法，那么这些线程都不能从缓存中查询到数据，那么他们就会在同一时刻访问数据库，执行SQL语句查询，对数据库访问压力过大
常见的解决方案有两种
- 互斥锁
- 逻辑过期
解决方案 1：互斥锁
- 用锁的互斥性，假设线程过来，只能一个人一个人的访问数据库，从而避免对数据库频繁访问产生过大压力，但这也会影响查询的性能，将查询的性能从并行变成了串行，我们可以采用tryLock方法+double check来解决这个问题
- 线程1在操作的时候，拿着锁把房门锁上了，那么线程2、3、4就不能都进来操作数据库，只有1操作完了，把房门打开了，此时缓存数据也重建好了，线程2、3、4直接从redis中就可以查询到数据。
解决方案 2：逻辑过期方案
- 方案分析：我们之所以会出现缓存击穿问题，主要原因是在于我们对key设置了TTL，如果我们不设置TTL，那么就不会有缓存击穿问题，但是不设置TTL，数据又会一直占用我们的内存，所以我们可以采用逻辑过期方案
- 我们之前是TTL设置在redis的value中，注意：这个过期时间并不会直接作用于Redis，而是我们后续通过逻辑去处理。假设线程1去查询缓存，然后从value中判断当前数据已经过期了，此时线程1去获得互斥锁，那么其他线程会进行阻塞，获得了锁的进程他会开启一个新线程去进行之前的重建缓存数据的逻辑，直到新开的线程完成者逻辑之后，才会释放锁，而线程1直接进行返回，假设现在线程3过来访问，由于线程2拿着锁，所以线程3无法获得锁，线程3也直接返回数据（但只能返回旧数据，牺牲了数据一致性，换取性能上的提高），只有等待线程2重建缓存数据之后，其他线程才能返回正确的数据
- 这种方案巧妙在于，异步构建缓存数据，缺点是在重建完缓存数据之前，返回的都是脏数据
2.8.1. 两种方案对比
- 互斥锁方案：由于保证了互斥性，所以数据一致，且实现简单，只是加了一把锁而已，也没有其他的事情需要操心，所以没有额外的内存消耗，缺点在于有锁的情况，就可能死锁，所以只能串行执行，性能会受到影响
- 逻辑过期方案：线程读取过程中不需要等待，性能好，有一个额外的线程持有锁去进行重构缓存数据，但是在重构数据完成之前，其他线程只能返回脏数据，且实现起来比较麻烦
| 解决方案 | 优点 | 缺点 |
| 互斥锁 | 没有额外的内存消耗 | 线程需要等待，性能受影响 |
| 逻辑过期 |
|
|
2.8.2. 利用互斥锁解决缓存击穿
- 核心思路：相较于原来从缓存中查询不到数据后直接查询数据库而言，现在的方案是，进行查询之后，如果没有从缓存中查询到数据，则进行互斥锁的获取，获取互斥锁之后，判断是否获取到了锁，如果没获取到，则休眠一段时间，过一会儿再去尝试，知道获取到锁为止，才能进行查询
- 如果获取到了锁的线程，则进行查询，将查询到的数据写入Redis，再释放锁，返回数据，利用互斥锁就能保证只有一个线程去执行数据库的逻辑，防止缓存击穿
- 操作锁的代码
- 核心思路就是利用redis的setIfAbsent方法来表示获取锁，如果redis没有这个key，则插入成功，返回1，如果已经存在这个key，则插入失败，返回0。在RedisTemplate中返回true/false，我们可以根据返回值来判断是否有线程成功获取到了锁
/**
* 获得锁
* @param key
* @return
*/
private boolean tryLock(String key){
Boolean flag = redisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
//避免返回为 null 值
return BooleanUtil.isTrue(flag);
}
/**
* 解锁
* @param key
*/
private void unLock(String key){
redisTemplate.delete(key);
}@Override
public Shop queryWithMutex(Long id) {
String shopKey = RedisConstants.CACHE_SHOP_KEY + id;
//先从Redis中查询
String shopJson = redisTemplate.opsForValue().get(shopKey).toString();
//如果不为空，则转换为shop对象，首先检查字符串 shopJson 是否为 null，然后再检查是否为空字符串
if(StrUtil.isNotBlank(shopJson)){
Shop shop = JSONUtil.toBean(shopJson, Shop.class);
return shop;
}
//如果查询到的是空字符串，则说明是缓存的空数据，只是检查 shopJson 是否为 null。
if(shopJson != null){
return null;
}
Shop shop = null;
try {
//获得锁
boolean flag = tryLock(shopKey);
//判断是否获得成功
if (!flag) {
//失败则进入休眠
Thread.sleep(50);
return queryWithMutex(id);
}
//否则去数据库查
shop = getById(id);
//查不到，将空字符串放入 Redis
if (shop == null) {
//设置存在时间 2 分钟
redisTemplate.opsForValue().set(RedisConstants.CACHE_SHOP_KEY + id, "", RedisConstants.CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
//查到了转为 JSON字符串
String jsonStr = JSONUtil.toJsonStr(shop);
//存入 Redis
redisTemplate.opsForValue().set(shopKey, jsonStr, RedisConstants.CACHE_SHOP_TTL, TimeUnit.MINUTES);
}catch (InterruptedException e){
throw new RuntimeException();
}finally {
unLock(shopKey);
}
return shop;
}修改 queryById
@Override
public Result queryById(Long id) {
Shop shop = queryWithMutex(id);
if (shop == null) {
return Result.fail("店铺不存在！！");
}
return Result.ok(shop);
}2.8.3. 利用逻辑过期解决缓存击穿问题
- 需求：根据id查询商铺的业务，基于逻辑过期方式来解决缓存击穿问题
- 思路分析：当用户开始查询redis时，判断是否命中
-
- 如果没有命中则直接返回空数据，不查询数据库
- 如果命中，则将value取出，判断value中的过期时间是否满足
-
-
- 如果没有过期，则直接返回redis中的数据
- 如果过期，则在开启独立线程后，直接返回之前的数据，独立线程去重构数据，重构完成后再释放互斥锁
-
编写一个实体类 shop，包含过期时间(expeirTime)
public class RedisData<T> {
private LocalDateTime expireTime;
private T data;
}编写流程代码
//声明一个线程池
private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);
/**
* 逻辑过期时间解决缓存击穿
* @param id
* @return
*/
public Shop queryWithLogicExpire(Long id){
//从 redis 中获取查询店铺缓存
String json = redisTemplate.opsForValue().get(RedisConstants.CACHE_SHOP_KEY + id).toString();
//如果为命中，返回为空
if(StrUtil.isBlank(json)){
return null;
}
//命中，将 json转换为对象
RedisData redisData = JSONUtil.toBean(json, RedisData.class);
//将 data 转换为诶 shop对象
JSONObject shopJson = (JSONObject) redisData.getData();
Shop shop = JSONUtil.toBean(shopJson, Shop.class);
//获取过期时间
LocalDateTime expireTime = redisData.getExpireTime();
//判断是否过期
if(LocalDateTime.now().isBefore(expireTime)){
//未过期，直接返回信息
return shop;
}
// 过期尝试获取互斥锁
boolean flag = tryLock(RedisConstants.CACHE_SHOP_KEY + id);
//获取到了锁
if(flag){
//开启一个独立线程
CACHE_REBUILD_EXECUTOR.submit(() -> {
try {
this.saveShop2Redis(id, RedisConstants.LOCK_SHOP_TTL);
}catch (Exception e){
throw new RuntimeException(e);
}finally {
unLock(RedisConstants.CACHE_SHOP_KEY + id);
}
});
//直接返回店铺信息
return shop;
}
//未获得锁，直接返回店铺信息
return shop;
}2.9. 工具类封装
@Slf4j
@Component
public class CacheClient {
private final StringRedisTemplate stringRedisTemplate;
private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);
public CacheClient(StringRedisTemplate stringRedisTemplate) {
this.stringRedisTemplate = stringRedisTemplate;
}
/**
* 将任意Java对象序列化为JSON，并存储到String类型的Key中，并可以设置TTL过期时间
* @param key
* @param value
* @param time
* @param timeUnit
*/
public void set(String key, Object value, Long time, TimeUnit timeUnit) {
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(value), time, timeUnit);
}
/**
* 将任意Java对象序列化为JSON，并存储在String类型的Key中，并可以设置逻辑过期时间，用于处理缓存击穿问题
* @param key
* @param value
* @param time
* @param timeUnit
*/
public void setWithLogicExpire(String key, Object value, Long time, TimeUnit timeUnit) {
RedisData<Object> redisData = new RedisData<>();
redisData.setData(value);
redisData.setExpireTime(LocalDateTime.now().plusSeconds(timeUnit.toSeconds(time)));
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(redisData));
}
/**
* 根据指定的Key查询缓存，并反序列化为指定类型，利用缓存空值的方式解决缓存穿透问题
* @param keyPrefix
* @param id
* @param type
* @param dbFallback
* @param time
* @param timeUnit
* @param <R>
* @param <ID>
* @return
*/
public <R, ID> R queryWithPassThrough(String keyPrefix, ID id, Class<R> type, Function<ID, R> dbFallback, Long time, TimeUnit timeUnit) {
//先从Redis中查，这里的常量值是固定的前缀 + 店铺id
String key = keyPrefix + id;
String json = stringRedisTemplate.opsForValue().get(key);
//如果不为空（查询到了），则转为R类型直接返回
if (StrUtil.isNotBlank(json)) {
return JSONUtil.toBean(json, type);
}
if (json != null) {
return null;
}
//否则去数据库中查，查询逻辑用我们参数中注入的函数
R r = dbFallback.apply(id);
//查不到，则将空值写入Redis
if (r == null) {
stringRedisTemplate.opsForValue().set(key, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
//查到了则转为json字符串
String jsonStr = JSONUtil.toJsonStr(r);
//并存入redis，设置TTL
this.set(key, jsonStr, time, timeUnit);
//最终把查询到的商户信息返回给前端
return r;
}
/**
* 根据指定的Key查询缓存，并反序列化为指定类型，需要利用逻辑过期解决缓存击穿问题
* @param keyPrefix
* @param id
* @param type
* @param dbFallback
* @param time
* @param timeUnit
* @param <R>
* @param <ID>
* @return
*/
public <R, ID> R queryWithLogicalExpire(String keyPrefix, ID id, Class<R> type, Function<ID, R> dbFallback, Long time, TimeUnit timeUnit) {
//1. 从redis中查询商铺缓存
String key = keyPrefix + id;
String json = stringRedisTemplate.opsForValue().get(key);
//2. 如果未命中，则返回空
if (StrUtil.isBlank(json)) {
return null;
}
//3. 命中，将json反序列化为对象
RedisData redisData = JSONUtil.toBean(json, RedisData.class);
R r = JSONUtil.toBean((JSONObject) redisData.getData(), type);
LocalDateTime expireTime = redisData.getExpireTime();
//4. 判断是否过期
if (expireTime.isAfter(LocalDateTime.now())) {
//5. 未过期，直接返回商铺信息
return r;
}
//6. 过期，尝试获取互斥锁
String lockKey = LOCK_SHOP_KEY + id;
boolean flag = tryLock(lockKey);
//7. 获取到了锁
if (flag) {
//8. 开启独立线程
CACHE_REBUILD_EXECUTOR.submit(() -> {
try {
R tmp = dbFallback.apply(id);
this.setWithLogicExpire(key, tmp, time, timeUnit);
} catch (Exception e) {
throw new RuntimeException(e);
} finally {
unlock(lockKey);
}
});
//9. 直接返回商铺信息
return r;
}
//10. 未获取到锁，直接返回商铺信息
return r;
}
/**
* 根据指定的Key查询缓存，并反序列化为指定类型，需要利用互斥锁解决缓存击穿问题
* @param keyPrefix
* @param id
* @param type
* @param dbFallback
* @param time
* @param timeUnit
* @param <R>
* @param <ID>
* @return
*/
public <R, ID> R queryWithMutex(String keyPrefix, ID id, Class<R> type, Function<ID, R> dbFallback, Long time, TimeUnit timeUnit) {
//先从Redis中查，这里的常量值是固定的前缀 + 店铺id
String key = keyPrefix + id;
String json = stringRedisTemplate.opsForValue().get(key);
//如果不为空（查询到了），则转为Shop类型直接返回
if (StrUtil.isNotBlank(json)) {
return JSONUtil.toBean(json, type);
}
if (json != null) {
return null;
}
R r = null;
String lockKey = LOCK_SHOP_KEY + id;
try {
//否则去数据库中查
boolean flag = tryLock(lockKey);
if (!flag) {
Thread.sleep(50);
return queryWithMutex(keyPrefix, id, type, dbFallback, time, timeUnit);
}
r = dbFallback.apply(id);
//查不到，则将空值写入Redis
if (r == null) {
stringRedisTemplate.opsForValue().set(key, "", CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
//并存入redis，设置TTL
this.set(key, r, time, timeUnit);
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
unlock(lockKey);
}
return r;
}
private boolean tryLock(String key) {
Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
return BooleanUtil.isTrue(flag);
}
private void unlock(String key) {
stringRedisTemplate.delete(key);
}
}参考播客：https://cyborg2077.github.io/2022/12/24/ElasticSearch/
扫一扫
6873
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
