缓存击穿问题也叫热点Key问题;就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了;无数的请求访问会在瞬间给数据库带来巨大的冲击。
常见的解决方案有两种;
互斥锁逻辑过期逻辑分析;假设线程1在查询缓存之后;本来应该去查询数据库;然后把这个数据重新加载到缓存的;此时只要线程1走完这个逻辑;其他线程就都能从缓存中加载这些数据了;但是假设在线程1没有走完的时候;后续的线程2;线程3;线程4同时过来访问当前这个方法; 那么这些线程都不能从缓存中查询到数据;那么他们就会同一时刻来访问查询缓存;都没查到;接着同一时间去访问数据库;同时的去执行数据库代码;对数据库访问压力过大
因为锁能实现互斥性。假设线程过来;只能一个人一个人的来访问数据库;从而避免对于数据库访问压力过大;但这也会影响查询的性能;因为此时会让查询的性能从并行变成了串行;我们可以采用tryLock方法 ; double check来解决这样的问题。
假设现在线程1过来访问;他查询缓存没有命中;但是此时他获得到了锁的资源;那么线程1就会一个人去执行逻辑;假设现在线程2过来;线程2在执行过程中;并没有获得到锁;那么线程2就可以进行到休眠;直到线程1把锁释放后;线程2获得到锁;然后再来执行逻辑;此时就能够从缓存中拿到数据了。
模拟操作锁代码实现; 核心思路就是利用redis的setnx方法来模拟获取锁;该方法含义是redis中如果没有这个key;则插入成功;返回1;stringRedisTemplate中返回true; 如果有这个key则插入失败;则返回0;在stringRedisTemplate返回false;我们可以通过true;或者是false;来表示是否有线程成功插入key;成功插入的key的线程我们认为他就是获得到锁的线程。
//模拟获取锁
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);
}
互斥锁解决缓存击穿代码实现;
//互斥锁解决缓存击穿
public Shop queryWithMutex(Long id) {
String key = CACHE_SHOP_KEY ; id;
// 1、从redis中查询商铺缓存
String shopJson = stringRedisTemplate.opsForValue().get(;key;);
// 2、判断是否存在
if (StrUtil.isNotBlank(shopJson)) {
// 存在,直接返回
return JSONUtil.toBean(shopJson, Shop.class);
}
//判断命中的值是否是空字符串;解决缓存穿透的空字符串 ;;;
if (shopJson == ;;) {
//返回一个错误信息
return null;
}
// 4.实现缓存重构
//4.1 获取互斥锁
String lockKey = LOCK_SHOP_KEY ; id;
Shop shop = null;
try {
boolean isLock = tryLock(lockKey);
// 4.2 判断否获取成功
if(!isLock){
//4.3 失败;则休眠重试
Thread.sleep(50);
return queryWithMutex(id);
}
//4.4 成功;根据id查询数据库
shop = getById(id);
//模拟重建的时间
Thread.sleep(3000);
// 5.不存在;返回错误
if(shop == null){
//将空值写入redis
stringRedisTemplate.opsForValue().set(key,;;,CACHE_NULL_TTL,TimeUnit.MINUTES);
//返回错误信息
return null;
}
//6.写入redis
stringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_NULL_TTL,TimeUnit.MINUTES);
}catch (Exception e){
throw new RuntimeException(e);
}
finally {
//7.释放互斥锁
unlock(lockKey);
}
return shop;
}
测试;
用JMeter模拟一百个线程并发访问;结果如下
设置访问地址、端口和请求方式;
返回结果;
方案分析;我们之所以会出现这个缓存击穿问题;主要原因是在于我们对key设置了过期时间;假设我们不设置过期时间;其实就不会有缓存击穿的问题;但是不设置过期时间;这样数据不就一直占用我们内存了吗;我们可以采用逻辑过期方案。
我们把过期时间设置在 redis的value中;注意;这个过期时间并不会直接作用于redis;而是我们后续通过逻辑去处理。假设线程1去查询缓存;然后从value中判断出来当前的数据已经过期了;此时线程1去获得互斥锁;那么其他线程会进行阻塞;获得了锁的线程他会开启一个 线程去进行 以前的重构数据的逻辑;直到新开的线程完成这个逻辑后;才释放锁; 而线程1直接进行返回;假设现在线程3过来访问;由于线程线程2持有着锁;所以线程3无法获得锁;线程3也直接返回数据;只有等到新开的线程2把重建数据构建完后;其他线程才能走返回正确的数据。
这种方案巧妙在于;异步的构建缓存;缺点在于在构建完缓存之前;返回的都是脏数据。
代码;
private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);
public Shop queryWithLogicalExpire( Long id ) {
String key = CACHE_SHOP_KEY ; id;
// 1.从redis查询商铺缓存
String json = stringRedisTemplate.opsForValue().get(key);
// 2.判断是否存在
if (StrUtil.isBlank(json)) {
// 3.不存在;直接返回
return null;
}
// 4.命中;需要先把json反序列化为对象
RedisData redisData = JSONUtil.toBean(json, RedisData.class);
Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);
LocalDateTime expireTime = redisData.getExpireTime();
// 5.判断是否过期
if(expireTime.isAfter(LocalDateTime.now())) {
// 5.1.未过期;直接返回店铺信息
return shop;
}
// 5.2.已过期;需要缓存重建
// 6.缓存重建
// 6.1.获取互斥锁
String lockKey = LOCK_SHOP_KEY ; id;
boolean isLock = tryLock(lockKey);
// 6.2.判断是否获取锁成功
if (isLock){
CACHE_REBUILD_EXECUTOR.submit( ()->{
try{
//重建缓存
this.saveShop2Redis(id,20L);
}catch (Exception e){
throw new RuntimeException(e);
}finally {
unlock(lockKey);
}
});
}
// 6.4.返回过期的商铺信息
return shop;
}
public void saveShop2Redis(Long id, Long expireSeconds) throws InterruptedException {
// 1.查询店铺数据
Shop shop = getById(id);
//模拟缓存重建时间
Thread.sleep(30);
// 2.封装逻辑过期时间
RedisData redisData = new RedisData();
redisData.setData(shop);
redisData.setExpireTime(LocalDateTime.now().plusSeconds(expireSeconds));
// 3.写入redis
stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY ; id, JSONUtil.toJsonStr(redisData));
}
测试;
目前的缓存已过期;前面请求的数据为110;没拿到锁的线程返回的脏数据。
缓存数据重建以后;返回新数据如下;
