经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Redis » 查看文章
【Redis场景3】缓存穿透、击穿问题
来源:cnblogs  作者:xbhog  时间:2023/2/1 9:38:42  对本文有异议

场景问题及原因

缓存穿透:

原因:客户端请求的数据在缓存和数据库中不存在,这样缓存永远不会生效,请求全部打入数据库,造成数据库连接异常。

解决思路:

  1. 缓存空对象

    1. 对于不存在的数据也在Redis建立缓存,值为空,并设置一个较短的TTL时间
    2. 问题:实现简单,维护方便,但短期的数据不一致问题

缓存雪崩:

原因:在同一时段大量的缓存key同时失效或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力。

解决思路:给不同的Key的TTL添加随机值(简单),给缓存业务添加降级限流策略(复杂),给业务添加多级缓存(复杂)

缓存击穿(热点Key):

前提条件:热点Key&在某一时段被高并发访问&缓存重建耗时较长

原因:热点key突然过期,因为重建耗时长,在这段时间内大量请求落到数据库,带来巨大冲击

解决思路:

  1. 互斥锁

    1. 给缓存重建过程加锁确保重建过程只有一个线程执行,其它线程等待
    2. 问题:线程阻塞,导致性能下降且有死锁风险
  2. 逻辑过期

    1. 热点key缓存永不过期,而是设置一个逻辑过期时间,查询到数据时通过对逻辑过期时间判断,来决定是否需要重建缓存;重建缓存也通过互斥锁保证单线程执行,但是重建缓存利用独立线程异步执行,其它线程无需等待,直接查询到的旧数据即可
    2. 问题:不保证一致性,有额外内存消耗且实现复杂

场景问题实践解决

完整代码地址:https://github.com/xbhog/hm-dianping

分支:20221221-xbhog-cacheBrenkdown

分支:20230110-xbhog-Cache_Penetration_Avalance

缓存穿透:

img

代码实现:

  1. public Shop queryWithPassThrough(Long id){
  2. //从redis查询商铺信息
  3. String shopInfo = stringRedisTemplate.opsForValue().get(SHOP_CACHE_KEY + id);
  4. //命中缓存,返回店铺信息
  5. if(StrUtil.isNotBlank(shopInfo)){
  6. return JSONUtil.toBean(shopInfo, Shop.class);
  7. }
  8. //redis既没有key的缓存,但查出来信息不为null,则为空字符串
  9. if(shopInfo != null){
  10. return null;
  11. }
  12. //未命中缓存
  13. Shop shop = getById(id);
  14. if(Objects.isNull(shop)){
  15. //将null添加至缓存,过期时间减少
  16. stringRedisTemplate.opsForValue().set(SHOP_CACHE_KEY+id,"",5L, TimeUnit.MINUTES);
  17. return null;
  18. }
  19. //对象转字符串
  20. stringRedisTemplate.opsForValue().set(SHOP_CACHE_KEY+id,JSONUtil.toJsonStr(shop),30L, TimeUnit.MINUTES);
  21. return shop;
  22. }

上述流程图和代码非常清晰,由于缓存雪崩简单实现(复杂实践不会)增加随机TTL值,缓存穿透和缓存雪崩不过多解释。

缓存击穿:

缓存击穿逻辑分析:

img

首先线程1在查询缓存时未命中,然后进行查询数据库并重建缓存。注意上述缓存击穿发生的条件,被高并发访问&缓存重建耗时较长;

由于缓存重建耗时较长,在这时间穿插线程2,3,4进入;那么这些线程都不能从缓存中查询到数据,同一时间去访问数据库,同时的去执行数据库操作代码,对数据库访问压力过大。

互斥锁:

解决方式:加锁;****可以采用**tryLock方法 + double check**来解决这样的问题

img

线程2执行的时候,由于线程1加锁在重建缓存,所以线程2被阻塞,休眠等待线程1执行完成后查询缓存。由此造成在重建缓存的时候阻塞进程,效率下降且有死锁的风险。

  1. private Shop queryWithMutex(Long id) {
  2. //从redis查询商铺信息
  3. String shopInfo = stringRedisTemplate.opsForValue().get(SHOP_CACHE_KEY + id);
  4. //命中缓存,返回店铺信息
  5. if(StrUtil.isNotBlank(shopInfo)){
  6. return JSONUtil.toBean(shopInfo, Shop.class);
  7. }
  8. //redis既没有key的缓存,但查出来信息不为null,则为空字符串
  9. if(shopInfo != null){
  10. return null;
  11. }
  12. //实现缓存重建
  13. String lockKey = "lock:shop:"+id;
  14. Shop shop = null;
  15. try {
  16. Boolean aBoolean = tryLock(lockKey);
  17. if(!aBoolean){
  18. //加锁失败,休眠
  19. Thread.sleep(50);
  20. //递归等待
  21. return queryWithMutex(id);
  22. }
  23. //获取锁成功应该再次检测redis缓存是否还存在,做doubleCheck,如果存在则无需重建缓存。
  24. synchronized (this){
  25. //从redis查询商铺信息
  26. String shopInfoTwo = stringRedisTemplate.opsForValue().get(SHOP_CACHE_KEY + id);
  27. //命中缓存,返回店铺信息
  28. if(StrUtil.isNotBlank(shopInfoTwo)){
  29. return JSONUtil.toBean(shopInfoTwo, Shop.class);
  30. }
  31. //redis既没有key的缓存,但查出来信息不为null,则为“”
  32. if(shopInfoTwo != null){
  33. return null;
  34. }
  35. //未命中缓存
  36. shop = getById(id);
  37. // 5.不存在,返回错误
  38. if(Objects.isNull(shop)){
  39. //将null添加至缓存,过期时间减少
  40. stringRedisTemplate.opsForValue().set(SHOP_CACHE_KEY+id,"",5L, TimeUnit.MINUTES);
  41. return null;
  42. }
  43. //模拟重建的延时
  44. Thread.sleep(200);
  45. //对象转字符串
  46. stringRedisTemplate.opsForValue().set(SHOP_CACHE_KEY+id,JSONUtil.toJsonStr(shop),30L, TimeUnit.MINUTES);
  47. }
  48. } catch (InterruptedException e) {
  49. throw new RuntimeException(e);
  50. } finally {
  51. unLock(lockKey);
  52. }
  53. return shop;
  54. }

在获取锁失败时,证明已有线程在重建缓存,使当前线程休眠并重试(递归实现)

代码中需要注意的是synchronized关键字的使用,在获取到锁的时候,在判断下缓存是否存在(失效)double-check,该关键字锁的是当前对象。在其关键字{}中是同步处理。

推荐博客https://blog.csdn.net/u013142781/article/details/51697672

然后进行测试代码,进行压力测试(jmeter),首先去除缓存中的值,模拟缓存失效。

设置1000个线程,多线程执行间隔5s

img

img

所有的请求都是成功的,其qps大约在200,其吞吐量还是比较可观的。然后看下缓存是否成功(只查询一次数据库);

img

逻辑过期:

思路分析:

当用户开始查询redis时,判断是否命中,如果没有命中则直接返回空数据,不查询数据库,而一旦命中后,将value取出,判断value中的过期时间是否满足,如果没有过期,则直接返回redis中的数据,如果过期,则在开启独立线程后直接返回之前的数据,独立线程去重构数据,重构完成后释放互斥锁。

img

封装数据:这里我们采用新建实体类来实现

  1. /**
  2. * @author xbhog
  3. * @describe:
  4. * @date 2023/1/15
  5. */
  6. @Data
  7. public class RedisData {
  8. private LocalDateTime expireTime;
  9. private Object data;
  10. }

使得过期时间和数据有关联关系,这里的数据类型是Object,方便后续不同类型的封装。

  1. public Shop queryWithLogicalExpire( Long id ) {
  2. String key = CACHE_SHOP_KEY + id;
  3. // 1.从redis查询商铺缓存
  4. String json = stringRedisTemplate.opsForValue().get(key);
  5. // 2.判断是否存在
  6. if (StrUtil.isBlank(json)) {
  7. // 3.存在,直接返回
  8. return null;
  9. }
  10. // 4.命中,需要先把json反序列化为对象
  11. RedisData redisData = JSONUtil.toBean(json, RedisData.class);
  12. Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);
  13. LocalDateTime expireTime = redisData.getExpireTime();
  14. // 5.判断是否过期
  15. if(expireTime.isAfter(LocalDateTime.now())) {
  16. // 5.1.未过期,直接返回店铺信息
  17. return shop;
  18. }
  19. // 5.2.已过期,需要缓存重建
  20. // 6.缓存重建
  21. // 6.1.获取互斥锁
  22. String lockKey = LOCK_SHOP_KEY + id;
  23. boolean isLock = tryLock(lockKey);
  24. // 6.2.判断是否获取锁成功
  25. if (isLock){
  26. exectorPool().execute(() -> {
  27. try {
  28. //重建缓存
  29. this.saveShop2Redis(id, 20L);
  30. } catch (Exception e) {
  31. throw new RuntimeException(e);
  32. } finally {
  33. unLock(lockKey);
  34. }
  35. });
  36. }
  37. // 6.4.返回过期的商铺信息
  38. return shop;
  39. }

当前的执行流程跟互斥锁基本相同,需要注意的是,在获取锁成功后,我们将缓存重建放到线程池中执行,来异步实现。

线程池代码:

  1. /**
  2. * 线程池的创建
  3. * @return
  4. */
  5. private static ThreadPoolExecutor exectorPool() {
  6. ThreadPoolExecutor executor = new ThreadPoolExecutor(
  7. 5,
  8. //根据自己的处理器数量+1
  9. Runtime.getRuntime().availableProcessors()+1,
  10. 2L,
  11. TimeUnit.SECONDS,
  12. new LinkedBlockingDeque<>(3),
  13. Executors.defaultThreadFactory(),
  14. new ThreadPoolExecutor.AbortPolicy());
  15. return executor;
  16. }

缓存重建代码:

  1. /**
  2. * 重建缓存
  3. * @param id 重建ID
  4. * @param l 过期时间
  5. */
  6. public void saveShop2Redis(Long id, long l) {
  7. //查询店铺信息
  8. Shop shop = getById(id);
  9. //封装逻辑过期时间
  10. RedisData redisData = new RedisData();
  11. redisData.setData(shop);
  12. redisData.setExpireTime(LocalDateTime.now().plusSeconds(l));
  13. stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY+id,JSONUtil.toJsonStr(redisData));
  14. }

测试条件100线程,1s线程间隔时间,缓存失效时间10s

测试环境:缓存中存在对应的数据,并且在缓存快失效之前修改数据库中的数据,造成缓存与数据库不一致,通过执行压测,来查看相关线程返回的数据情况。

img

img

从上述两张图中可以看到,在前几个线程执行过程中店铺name为102,当执行时间从19-20的时候店铺name发生变化为105,满足逻辑过期异步执行缓存重建的需求.

原文链接:https://www.cnblogs.com/xbhog/p/17076595.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号