IT评测·应用市场-qidao123.com

标题: day03-商家查询缓存02 [打印本页]

---

作者: 东湖之滨    时间: 2023-4-20 23:20
标题: day03-商家查询缓存02
功能02-商铺查询缓存02

知识补充

(1)缓存穿透

https://blog.csdn.net/qq_45637260/article/details/125866738

缓存穿透（cache penetration）是指用户访问的数据既不在缓存当中，也不在数据库中。出于容错的考虑，如果从底层数据库查询不到数据，则不写入缓存。这就导致每次请求都会到底层数据库进行查询，缓存也失去了意义。当高并发或有人利用不存在的Key频繁攻击时，数据库的压力骤增，甚至崩溃，这就是缓存穿透问题。
简单地说，缓存穿透是指用户请求的数据在缓存和数据库中都不存在，则每次请求都会打到数据库中，给数据库带来巨大压力。
常见的两种解决方案
（1）缓存空对象：是指在持久层没有命中的情况下，对key进行set （key，null）。
缓存空对象会有两个问题：

• value为null 不代表不占用内存空间，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
  
• 缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
  

（2）布隆过滤器：
在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截，当收到一个对key请求时，先用布隆过滤器验证是key否存在，如果存在再进入缓存层、存储层。

可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景，代码维护较为复杂，但是缓存空间占用少。

布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
布隆过滤器拦截的算法描述：
初始状态时，BloomFilter是一个长度为m的位数组，每一位都置为0。添加元素x时，x使用k个hash函数得到k个hash值，对m取余，对应的bit位设置为1。
判断y是否属于这个集合，对y使用k个哈希函数得到k个哈希值，对m取余，所有对应的位置都是1，则认为y属于该集合（哈希冲突，可能存在误判），否则就认为y不属于该集合。可以通过增加哈希函数和增加二进制位数组的长度来降低错报率
两种方案的比较：
缓存穿透的方案使用场景维护成本缓存空对象1.数据命中率不高 2.数据频繁变化实时性高1.代码维护简单 2.需要过多的缓存空间 3.数据不一致布隆过滤器1.数据命中不高 2.数据相对固定实时性低1.代码维护复杂 2.缓存空间占用少缓存穿透的解决方案还有：
(2)缓存雪崩

缓存雪崩
在使用缓存时，通常会对缓存设置过期时间，一方面目的是保持缓存与数据库数据的一致性，另一方面是减少冷缓存占用过多的内存空间。但当缓存中大量热点缓存采用了相同的实效时间，就会导致缓存在某一个时刻同时实效，请求全部转发到数据库，从而导致数据库压力骤增，甚至宕机。从而形成一系列的连锁反应，造成系统崩溃等情况，这就是缓存雪崩（Cache Avalanche）。
简单地说，缓存雪崩是指在同一时间段大量的热点key同时失效，或者Redis服务宕机，导致大量请求到达数据库，给数据库带来巨大压力。
解决方案

• 给不同的key的TTL添加随机值（比如随机1-5分钟），让key均匀地失效
  
• 利用redis集群提高服务的可用性（提高高可用性）
  
• 给缓存业务添加熔断、降级、限流策略
  
• 给业务添加多级缓存
  

(3)缓存击穿

缓存击穿
如果有一个热点key，在不停的扛着大并发，在这个key失效的瞬间，持续的大并发请求就会击破缓存，直接请求到数据库，好像蛮力击穿一样。这种情况就是缓存击穿（Cache Breakdown）。
缓存击穿问题也叫做热点key问题，简单来说，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问在瞬间给数据库带来巨大的冲击。

从定义上可以看出，缓存击穿和缓存雪崩很类似，只不过是缓存击穿是一个热点key失效，而缓存雪崩是大量热点key失效。因此，可以将缓存击穿看作是缓存雪崩的一个子集。

解决方案
方案一：使用互斥锁（Mutex Key），只让一个线程构建缓存，其他线程等待构建缓存执行完毕，重新从缓存中获取数据。单机通过synchronized或lock来处理，分布式环境采用分布式锁。
方案二：逻辑过期。热点数据不设置过期时间，只在value中设置逻辑上的过期时间。后台异步更新缓存，适用于不严格要求缓存一致性的场景。
两种方案的对比：
3.功能02-商铺查询缓存

3.4查询商铺id的缓存穿透问题

3.4.3需求分析

解决查询商铺查询可能存在的缓存穿透问题：当访问不存在的店铺时，请求会直接打到数据库上，并且redis缓存永远不会生效。
这里使用缓存空对象的方式来解决。
3.4.4代码实现

（1）修改ShopServiceImpl.java的queryById方法

1. @Override
2. public Result queryById(Long id) {
3.     String key = CACHE_SHOP_KEY + id;
5.     //1.从redis中查询商铺缓存
6.     String shopJson = stringRedisTemplate.opsForValue().get(key);
8.     //2.判断缓存是否命中
9.     if (StrUtil.isNotBlank(shopJson)) {
10.         //2.1若命中，直接返回商铺信息
11.         Shop shop = JSONUtil.toBean(shopJson, Shop.class);
12.         return Result.ok(shop);
13.     }
14.     //判断命中的是否是redis的空值
15.     if (shopJson != null) {
16.         return Result.fail("店铺不存在！");
17.     }
19.     //2.2未命中，根据id查询数据库，判断商铺是否存在数据库中
20.     Shop shop = getById(id);
21.     if (shop == null) {
22.         //2.2.1不存在，防止缓存穿透，将空值存入redis，TTL设置为2min
23.         stringRedisTemplate.opsForValue().set(key, "",
24.                 CACHE_NULL_TTL, TimeUnit.MINUTES);
25.         //返回错误信息
26.         return Result.fail("店铺不存在！");
27.     }
29.     //2.2.2存在，则将商铺数据写入redis中
30.     stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop),
31.             CACHE_SHOP_TTL, TimeUnit.MINUTES);
33.     return Result.ok(shop);
34. }

复制代码

（2）测试，访问一个缓存和数据库都不存在的数据：
可以看到redis已经缓存了一个空值

之后再访问该数据，只要redis的空值对没有过期，就不会访问到数据库，从而起到保护数据库的作用。
3.5查询商铺id的缓存击穿问题

当查询店铺id时，可能会出现该店铺id对应的缓存失效，从而大量请求发送到数据库的情况，这里使用两种方案分别解决该问题。
3.5.1基于互斥锁方案解决

3.5.1.1需求分析

修改根据id查询商铺的业务，基于互斥锁方式来解决缓存击穿问题。
如下，当出现缓存击穿问题，首先需要判断当前的线程是否能够获取锁：

• 若可以，则进行缓存重建（将数据库数据重新写入缓存中），然后释放锁。
  
• 如果不能，则线程等待一段时间，然后再判断缓存是否能命中。
  
  
  
  • 如果未命中，则重复获取锁的流程，直到缓存命中，或者获得锁，重建缓存。
    
  
  

根据redis的setnx命令，当setnx设置某个key之后，如果该key存在，则其他线程无法设置该key。
我们可以根据这个特性，作为一个lock的逻辑标志，当一个线程setnx某个key后，代表获取了“锁”。当删除这个key时，代表释放“锁”，这样其他线程就可以重新获取“锁”。此外，可以对该key设置一个有效期，防止删除key失败，产生“死锁”。
3.5.1.2代码实现

（1）修改 ShopServiceImpl.java

1. package com.hmdp.service.impl;
3. import ...
5. /**
6. * 服务实现类
7. *
8. * @author 李
9. * @version 1.0
10. */
11. @Service
12. public class ShopServiceImpl extends ServiceImpl<ShopMapper, Shop>
13.         implements IShopService {
14.     @Resource
15.     StringRedisTemplate stringRedisTemplate;
17.     @Override
18.     public Result queryById(Long id) {
19.         Shop shop = queryWithMutex(id);
20.         if (shop == null) {
21.             return Result.fail("店铺不存在！");
22.         }
23.         return Result.ok(shop);
24.     }
26.     //缓存穿透(存储空对象)+缓存击穿解决(互斥锁解决)
27.     public Shop queryWithMutex(Long id) {
28.         String key = CACHE_SHOP_KEY + id;
29.         //从redis中查询商铺缓存
30.         String shopJson = stringRedisTemplate.opsForValue().get(key);
31.         //判断缓存是否命中
32.         if (StrUtil.isNotBlank(shopJson)) {
33.             //命中，直接返回商铺信息
34.             return JSONUtil.toBean(shopJson, Shop.class);
35.         }
36.         //判断命中的是否是redis的空值（缓存击穿解决）
37.         if (shopJson != null) {
38.             return null;
39.         }
40.         //未命中，尝试获取互斥锁
41.         String lockKey = "lock:shop:" + id;
42.         boolean isLock = false;
43.         Shop shop = null;
44.         try {
45.             //获取互斥锁
46.             isLock = tryLock(lockKey);
47.             //判断是否获取成功
48.             if (!isLock) {//失败
49.                 //等待并重试
50.                 Thread.sleep(50);
51.                 //直到缓存命中，或者获取到锁
52.                 return queryWithMutex(id);
53.             }
54.             //获取锁成功，开始重建缓存
55.             //根据id查询数据库，判断商铺是否存在数据库中
56.             shop = getById(id);
57.             //模拟重建缓存的延迟-----------
58.             Thread.sleep(200);
59.             if (shop == null) {
60.                 //不存在，防止缓存穿透，将空值存入redis，TTL设置为2min
61.                 stringRedisTemplate.opsForValue().set(key, "",
62.                         CACHE_NULL_TTL, TimeUnit.MINUTES);
63.                 //返回错误信息
64.                 return null;
65.             }
66.             //存在，则将商铺数据写入redis中
67.             stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop),
68.                     CACHE_SHOP_TTL, TimeUnit.MINUTES);
69.         } catch (InterruptedException e) {
70.             throw new RuntimeException(e);
71.         } finally {
72.             //释放互斥锁
73.             unLock(lockKey);
74.         }
75.         //返回从缓存或数据库中查到的数据
76.         return shop;
77.     }
79.     //缓存穿透方案
80. //    public Shop queryWithPassThrough(Long id) {
81. //        String key = CACHE_SHOP_KEY + id;
82. //        //1.从redis中查询商铺缓存
83. //        String shopJson = stringRedisTemplate.opsForValue().get(key);
84. //        //2.判断缓存是否命中
85. //        if (StrUtil.isNotBlank(shopJson)) {
86. //            //2.1若命中，直接返回商铺信息
87. //            return JSONUtil.toBean(shopJson, Shop.class);
88. //        }
89. //        //判断命中的是否是redis的空值
90. //        if (shopJson != null) {
91. //            return null;
92. //        }
93. //        //2.2未命中，根据id查询数据库，判断商铺是否存在数据库中
94. //        Shop shop = getById(id);
95. //        if (shop == null) {
96. //            //2.2.1不存在，防止缓存穿透，将空值存入redis，TTL设置为2min
97. //            stringRedisTemplate.opsForValue().set(key, "",
98. //                    CACHE_NULL_TTL, TimeUnit.MINUTES);
99. //            //返回错误信息
100. //            return null;
101. //        }
102. //        //2.2.2存在，则将商铺数据写入redis中
103. //        stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop),
104. //                CACHE_SHOP_TTL, TimeUnit.MINUTES);
105. //        return shop;
106. //    }
108.     private boolean tryLock(String key) {
109.         Boolean flag = stringRedisTemplate.opsForValue()
110.                 .setIfAbsent(key, "1", 10, TimeUnit.SECONDS);
111.         return BooleanUtil.isTrue(flag);
112.     }
114.     private void unLock(String key) {
115.         stringRedisTemplate.delete(key);
116.     }
118.     @Override
119.     @Transactional
120.     public Result update(Shop shop) {
121.         Long id = shop.getId();
122.         if (id == null) {
123.             return Result.fail("店铺id不能为空");
124.         }
125.         //1.更新数据库
126.         updateById(shop);
127.         //2.删除redis缓存
128.         stringRedisTemplate.delete(CACHE_SHOP_KEY + id);
129.         return Result.ok();
130.     }
131. }

复制代码

（2）使用jemeter模拟高并发的情况：
5秒发起1000个请求线程：
模拟http请求：
全部请求成功，获取到数据：
在服务器的控制台中可以看到：对于数据库的请求只触发了一次，证明在高并发的场景下，只有一个线程对数据库发起请求，并对redis对应的缓存重新设置。
3.5.2基于逻辑过期方案解决


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

---

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)

Powered by Discuz! X3.4