Redis更新策略
- 内存淘汰:Redis自带的内存淘汰机制
- 过期淘汰:利用expire命令给数据设置过期时间
- 主动更新:主动完成数据库与缓存的同时更新
根据一致性选择不同的更新策略,如果不那么注重一致性选择内存淘汰、过期淘汰即可。如果对于一致性要求较高可以选择主动更新,并用过期淘汰兜底。
主动更新
主动更新又分为三大更新方式
-
Cache Aside:缓存调用者在更新数据库的同时完成对完成的更新
优点: 一致性良好、实现难度一般
-
Read/Write Through:缓存与数据库集成为一个服务,服务保证两者的一致性,对外暴露API接口。调用者调用API,无需知道自己操作的是数据库还是缓存,不关心一致性。
优点:一致性优秀、实现复杂、性能一般
-
Write Back:缓存调用者的CRUD都针对缓存完成。由独立线程异步的将缓存数据写到数据库,实现最终一致
优点:一致性差、性能好、实现复杂
现在我主要学习了Cache Aside,对于大多数中小型企业其实没有特别多的访问量,后两个成本还是偏高了,所以Cache Aside仍是主要的解决方案
对于Cache Aside而言还存在着 先更新数据库还是先删缓存 的问题
一般情况来说先更新数据库后删缓存是更优解,但是要保证满足原子性,也就是加入@Transactional注解或者分布式实现。
缓存穿透
客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库
对于这样的情况可以选择多种解决方案
- 缓存空对象
- 布隆过滤
- 其他
缓存空对象
当请求一个数据库和缓存都没有的值时,在查询数据库为空后,向redis存入一个key为查询值的空值,防止下次再次请求数据库
优点:实现简单,维护方便
缺点:额外的内存消耗、短期的数据不一致问题
例如
public Shop queryWithPassThrough(Long id){
// 缓存穿透
String key = RedisConstants.CACHE_SHOP_KEY + id;
//从redis查询商铺缓存
String shopJson = stringRedisTemplate.opsForValue().get(key);
//判断是否存在
if(StrUtil.isNotBlank(shopJson)){
//存在,直接返回
Shop shop = JSONUtil.toBean(shopJson, Shop.class);
return shop;
}
//如果命中的是空值那么不需要继续查了
if(shopJson != null){
return null;
}
Shop shop = getById(id);
if(shop == null){
//不存在,将null写入redis
stringRedisTemplate.opsForValue().set(key, "",CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);
return shop;
}
布隆过滤
利用布隆过滤算法,在请求进入Redis之前先判断是否存在,如果不存在则直接拒绝请求
优点:内存占用少
缺点:实现复杂、存在误判的可能性(100%拦截不存在的,也有可能拦截到存在的)
其他
- 做好数据的基础格式校验
- 加强用户权限校验
- 做好热点参数的限流
缓存击穿(热点key)
产生原因:
- 热点Key在某一时段被高并发访问或者缓存重建耗时较长
- 热点key突然过期,因为重建耗时长,在这段时间内大量请求落到数据库,带来巨大冲击
解决方案
1. 互斥锁
思路:给缓存重建过程加锁,确保重建过程只有一个线程执行,其它线程等待
优点:实现简单、没有额外内存消耗、一致性好
缺点:等待导致性能下降、有死锁风险
例如
public Shop queryWithMutex(Long id){
Shop shop = null;
// 缓存穿透
String key = RedisConstants.CACHE_SHOP_KEY + id;
//从redis查询商铺缓存
String shopJson = stringRedisTemplate.opsForValue().get(key);
//判断是否存在
if(StrUtil.isNotBlank(shopJson)){
//存在,直接返回
shop = JSONUtil.toBean(shopJson, Shop.class);
return shop;
}
//如果命中的是空值那么不需要继续查了
if(shopJson != null){
return null;
}
//实现缓存重建
//获取互斥锁
String lockKey = RedisConstants.LOCK_SHOP_KEY + id;
try {
boolean isLock = tryLock(lockKey);
if(!isLock){
//失败了,休眠并重试
Thread.sleep(50);
return queryWithMutex(id);
}
shop = getById(id);
Thread.sleep(200);
if(shop == null){
//不存在,将null写入redis
stringRedisTemplate.opsForValue().set(key, "",CACHE_NULL_TTL, TimeUnit.MINUTES);
return null;
}
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop),CACHE_SHOP_TTL, TimeUnit.MINUTES);
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
//释放锁
unLock(lockKey);
}
return shop;
}
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);
}
2.逻辑过期
思路:
- 热点key缓存永不过期,而是设置一个逻辑过期时间,查询到数据时通过对逻辑过期时间判断,来决定是否需要重建缓存
- 重建缓存也通过互斥锁保证单线程执行
- 重建缓存利用独立线程异步执行
- 其它线程无需等待,直接查询到的旧数据即可
优点:线程无需等待,性能较好
缺点:不保证一致性、有额外内存消耗、实现复杂
例如
public Shop queryWithLogicalExpire(Long id){
// 缓存穿透
String key = RedisConstants.CACHE_SHOP_KEY + id;
//从redis查询商铺缓存
String shopJson = stringRedisTemplate.opsForValue().get(key);
//判断是否存在
if(StrUtil.isBlank(shopJson)){
return null;
}
//命中,需要先把json反序列化为对象
RedisData redisData = JSONUtil.toBean(shopJson, RedisData.class);
JSONObject data =(JSONObject) redisData.getData();
Shop shop = JSONUtil.toBean(data, Shop.class);
LocalDateTime expireTime = redisData.getExpireTime();
//判断是否过期
if(expireTime.isAfter(LocalDateTime.now())){
//未过期,直接返回店铺信息
return shop;
}
//已过期,需要缓存重建
//缓存重建
//获取互斥锁
String lockKey = RedisConstants.LOCK_SHOP_KEY + id;
boolean isLock = tryLock(lockKey);
if (isLock){
//如果成功开启独立线程,实现缓存重建
CACHE_REBUILD_EXECUTOR.submit(() -> {
try {
this.saveShop2Redis(id,10L);
} catch (Exception e) {
throw new RuntimeException(e);
}finally {
//释放锁
unLock(lockKey);
}
});
}
//返回过期的商品信息
return shop;
}
缓存雪崩
产生原因:在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力。
解决方案
- 给不同的Key的TTL添加随机值
- 利用Redis集群提高服务的可用性
- 给缓存业务添加降级限流策略
- 给业务添加多级缓存