Redis实战(黑马点评--商户查询缓存)
为什么使用缓存
添加商户缓存
ShopController层
/** * 根据id查询商铺信息 * @param id 商铺id * @return 商铺详情数据 */ @GetMapping("/{id}") public Result queryShopById(@PathVariable("id") Long id) { return shopService.queryById(id); }
ServiceImpl层
@Override public Result queryById(Long id) { //先从Redis中查,这里的常量值是固定的前缀 + 店铺id String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id); //如果不为空(查询到了),则转为Shop类型直接返回 if (StrUtil.isNotBlank(shopJson)) { Shop shop = JSONUtil.toBean(shopJson, Shop.class); return Result.ok(shop); } //否则去数据库中查 Shop shop = getById(id); //查不到返回一个错误信息或者返回空都可以,根据自己的需求来 if (shop == null){ return Result.fail("店铺不存在!!"); } //查到了则转为json字符串 String jsonStr = JSONUtil.toJsonStr(shop); //并存入redis stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr); //最终把查询到的商户信息返回给前端 return Result.ok(shop); }
缓存更新策略
- 缓存更新是Redis为了节约内存而设计出来的一个东西,主要是因为内存数据宝贵,当我们想Redis插入太多数据,此时就可能会导致缓存中数据过多,所以Redis会对部分数据进行更新,或者把它成为淘汰更合适
内存淘汰
:Redis自动进行,当Redis内存大道我们设定的max-memery
时,会自动触发淘汰机制,淘汰掉一些不重要的数据(可以自己设置策略方式)超时剔除
:当我们给Redis设置了过期时间TTL之后,Redis会将超时的数据进行删除,方便我们继续使用缓存主动更新
:我们可以手动调用方法把缓存删除掉,通常用于解决缓存和数据库不一致问题
内存淘汰 | 超时剔除 | 主动更新 | |
说明 | 不用自己维护, 利用Redis的内存淘汰机制, 当内存不足时自动淘汰部分数据。 下次查询时更新缓存。 |
给缓存数据添加TTL时间, 到期后自动删除缓存。 下次查询时更新缓存。 |
编写业务逻辑, 在修改数据库的同时, 更新缓存。 |
一致性 | 差 | 一般 | 好 |
维护成本 | 无 | 低 | 高 |
- 业务场景
- 低一致性需求:使用内存淘汰机制,例如店铺类型的查询缓存(因为这个很长一段时间都不需要更新)
- 高一致性需求:主动更新,并以超时剔除作为兜底方案,例如店铺详情查询的缓存
主动更新策略
- 企业应用中,方案一更加可靠。假设我们每次操作完数据库之后,都去更新一下缓存,但是如果中间并没有人查询数据,那么这个更新动作只有最后一次是有效的,中间的更新动作意义不大,所以我们可以把缓存直接删除,等到有人再次查询时,再将缓存中的数据加载出来。三个问题↓
- 删除缓存还是更新缓存?
更新缓存
:每次更新数据库都需要更新缓存,无效写操作较多- 删除缓存:更新数据库时让缓存失效,再次查询时更新缓存
- 如何保证缓存与数据库的操作同时成功或同时失败?
单体系统:
将缓存与数据库操作放在同一个事务分布式系统:
利用TCC等分布式事务方案
- 先操作缓存还是先操作数据库?
- 先删除缓存,再操作数据库
- 删除缓存的操作很快,但是更新数据库的操作相对较慢,如果此时有一个线程2刚好进来查询缓存,由于我们刚刚才删除缓存,所以线程2需要查询数据库,并写入缓存,但是我们更新数据库的操作还未完成,所以线程2查询到的数据是脏数据,出现线程安全问题。正常情况&异常情况
-
-
- 先操作数据库,再删除缓存
- 线程1在查询缓存的时候,缓存TTL刚好失效,需要查询数据库并写入缓存,这个操作耗时相对较短(相比较于上图来说),但是就在这么短的时间内,线程2进来了,更新数据库,删除缓存,但是线程1虽然查询完了数据(更新前的旧数据),但是还没来得及写入缓存,所以线程2的更新数据库与删除缓存,并没有影响到线程1的查询旧数据,写入缓存,造成线程安全问题
-
-
- 先删除缓存,再操作数据库
-
-
虽然这二者都存在线程安全问题,但是相对来说,后者出现线程安全问题的概率相对较低(redis的key失效的情况下),所以我们最终采用后者
先操作数据库,再删除缓存
的方案
-
缓存更新策略的最佳实践方案
- 低一致性需求:使用Redis自带的内存淘汰机制
- 高一致性需求:主动更新,并以超时剔除作为兜底方案
-
- 读操作:
- 缓存命中则直接返回。
- 缓存未命中则查询数据库,并写入缓存,设定超时时间。
- 写操作:
- 先写数据库,然后再删除缓存。
- 要确保数据库与缓存操作的原子性。
- 读操作:
实现商铺缓存与数据库双写一致
-
核心思路如下
- 修改ShopController中的业务逻辑,满足以下要求
- 根据id查询店铺时,如果缓存未命中,则查询数据库,并将数据库结果写入缓存,并设置TTL
- 根据id修改店铺时,先修改数据库,再删除缓存
查询操作
@Override public Result queryById(Long id) { // 1.先从Redis中查,这里的常量值是固定的前缀 + 店铺id String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id); // 2.如果不为空(查询到了),则转为Shop类型直接返回 if (StrUtil.isNotBlank(shopJson)) { Shop shop = JSONUtil.toBean(shopJson, Shop.class); return Result.ok(shop); } // 3.否则去数据库中查 Shop shop = getById(id); // 4.查不到返回一个错误信息或者返回空都可以,根据自己的需求来 if (shop == null){ return Result.fail("店铺不存在!!"); } // 5.查到了则转为json字符串,并存入redis String jsonStr = JSONUtil.toJsonStr(shop); stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr, CACHE_SHOP_TTL, TimeUnit.MINUTES); //最终把查询到的商户信息返回给前端 return Result.ok(shop); }
更新操作
/** * 更新商铺信息 * @param shop 商铺数据 * @return 无 */ @PutMapping public Result updateShop(@RequestBody Shop shop) { // 写入数据库 //shopService.updateById(shop); return shopService.update(shop); }
@Override public Result update(Shop shop) { if (shop.getId() == null) { return Result.fail("店铺id不能为空!!"); } // 1.更新数据库 updateById(shop); // 2.删除缓存 stringRedisTemplate.delete(CACHE_SHOP_KEY + shop.getId()); return Result.ok(); }
- 之后再Redis图形化页面刷新数据,发现该餐厅的数据确实不在Redis中了,之后我们刷新网页,餐厅名会被更改,然后我们再去Redis中刷新,发现新数据已经被缓存了
- 那么现在功能就实现完毕了,只有当我们刷新页面的时候,才会重新查询数据库,并将数据缓存到Redis,中途无论修改多少次,只要不刷新页面访问,Redis中都不会更新数据
缓存穿透的解决思路
缓存穿透
:缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远都不会生效(只有数据库查到了,才会让redis缓存,但现在的问题是查不到),会频繁的去访问数据库。- 解决方案
- 缓存空对象
- 优点:实现简单,方便维护
- 缺点:额外的内存消耗,可能造成短期的不一致
- 布隆过滤
- 内存占用少,没有多余的key
- 缺点:实现复杂,可能存在误判
- 缓存空对象
-
缓存空对象
思路分析:当我们客户端访问不存在的数据时,会先请求redis,但是此时redis中也没有数据,就会直接访问数据库,但是数据库里也没有数据,那么这个数据就穿透了缓存,直击数据库。但是数据库能承载的并发不如redis这么高,所以如果大量的请求同时都来访问这个不存在的数据,那么这些请求就会访问到数据库,简单的解决方案就是哪怕这个数据在数据库里不存在,我们也把这个这个数据存在redis中去(这就是为啥说会有额外的内存消耗
),这样下次用户过来访问这个不存在的数据时,redis缓存中也能找到这个数据,不用去查数据库。可能造成的短期不一致
是指在空对象的存活期间,我们更新了数据库,把这个空对象变成了正常的可以访问的数据,但由于空对象的TTL还没过,所以当用户来查询的时候,查询到的还是空对象,等TTL过了之后,才能访问到正确的数据,不过这种情况很少见罢了 -
布隆过滤
思路分析:布隆过滤器其实采用的是哈希思想来解决这个问题,通过一个庞大的二进制数组,根据哈希思想去判断当前这个要查询的数据是否存在,如果布隆过滤器判断存在,则放行,这个请求会去访问redis,哪怕此时redis中的数据过期了,但是数据库里一定会存在这个数据,从数据库中查询到数据之后,再将其放到redis中。如果布隆过滤器判断这个数据不存在,则直接返回。这种思想的优点在于节约内存空间,但存在误判,误判的原因在于:布隆过滤器使用的是哈希思想,只要是哈希思想,都可能存在哈希冲突
解决商品查询的缓存穿透问题
@Override public Result queryById(Long id) { // 1.先从Redis中查,这里的常量值是固定的前缀 + 店铺id String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id); // 2.如果不为空(查询到了),则转为Shop类型直接返回 if (StrUtil.isNotBlank(shopJson)) { Shop shop = JSONUtil.toBean(shopJson, Shop.class); return Result.ok(shop); } // 2.2 判断空值(不能直接进数据库查询) if (shopJson != null) { return Result.fail("店铺不存在!!"); } // 3.否则去数据库中查 Shop shop = getById(id); // 4.查不到返回一个错误信息或者返回空都可以,根据自己的需求来 if (shop == null){ // 将空值写入redis stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, "", CACHE_NULL_TTL, TimeUnit.MINUTES); return Result.fail("店铺不存在!!"); } // 5.查到了则转为json字符串,并存入redis String jsonStr = JSONUtil.toJsonStr(shop); stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr, CACHE_SHOP_TTL, TimeUnit.MINUTES); //最终把查询到的商户信息返回给前端 return Result.ok(shop); }
缓存雪崩及解决思路
- 缓存雪崩是指在同一时间段,大量缓存的key同时失效,或者Redis服务宕机,导致大量请求到达数据库,带来巨大压力
- 解决方案
- 给不同的Key的TTL添加随机值,让其在不同时间段分批失效
- 利用Redis集群提高服务的可用性(使用一个或者多个哨兵(
Sentinel
)实例组成的系统,对redis节点进行监控,在主节点出现故障的情况下,能将从节点中的一个升级为主节点,进行故障转义,保证系统的可用性。 ) - 给缓存业务添加降级限流策略
- 给业务添加多级缓存(浏览器访问静态资源时,优先读取浏览器本地缓存;访问非静态资源(ajax查询数据)时,访问服务端;请求到达Nginx后,优先读取Nginx本地缓存;如果Nginx本地缓存未命中,则去直接查询Redis(不经过Tomcat);如果Redis查询未命中,则查询Tomcat;请求进入Tomcat后,优先查询JVM进程缓存;如果JVM进程缓存未命中,则查询数据库)
缓存击穿问题及解决思路
- 缓存击穿也叫热点Key问题,就是一个被
高并发访问
并且缓存重建业务较复杂
的key突然失效了,那么无数请求访问就会在瞬间给数据库带来巨大的冲击 - 举个不太恰当的例子:一件秒杀中的商品的key突然失效了,大家都在疯狂抢购,那么这个瞬间就会有无数的请求访问去直接抵达数据库,从而造成缓存击穿
- 常见的解决方案有两种
- 互斥锁
- 逻辑过期
逻辑分析
:假设线程1在查询缓存之后未命中,本来应该去查询数据库,重建缓存数据,完成这些之后,其他线程也就能从缓存中加载这些数据了。但是在线程1还未执行完毕时,又进来了线程2、3、4同时来访问当前方法,那么这些线程都不能从缓存中查询到数据,那么他们就会在同一时刻访问数据库,执行SQL语句查询,对数据库访问压力过大。
-
解决方案一
:互斥锁 - 利用锁的互斥性,假设线程过来,只能一个人一个人的访问数据库,从而避免对数据库频繁访问产生过大压力,但这也会影响查询的性能,将查询的性能从并行变成了串行,我们可以采用tryLock方法+double check来解决这个问题
- 线程1在操作的时候,拿着锁把房门锁上了,那么线程2、3、4就不能都进来操作数据库,只有1操作完了,把房门打开了,此时缓存数据也重建好了,线程2、3、4直接从redis中就可以查询到数据。
解决方案二
:逻辑过期方案- 方案分析:我们之所以会出现缓存击穿问题,主要原因是在于我们对key设置了TTL,如果我们不设置TTL,那么就不会有缓存击穿问题,但是不设置TTL,数据又会一直占用我们的内存,所以我们可以采用逻辑过期方案
- 我们之前是TTL设置在redis的value中,注意:这个过期时间并不会直接作用于Redis,而是我们后续通过逻辑去处理。假设线程1去查询缓存,然后从value中判断当前数据已经过期了,此时线程1去获得互斥锁,那么其他线程会进行阻塞,获得了锁的进程他会开启一个新线程去进行之前的重建缓存数据的逻辑,直到新开的线程完成者逻辑之后,才会释放锁,而线程1直接进行返回,假设现在线程3过来访问,由于线程2拿着锁,所以线程3无法获得锁,线程3也直接返回数据(但只能返回旧数据,牺牲了数据一致性,换取性能上的提高),只有等待线程2重建缓存数据之后,其他线程才能返回正确的数据
- 这种方案巧妙在于,异步构建缓存数据,缺点是在重建完缓存数据之前,返回的都是脏数据
互斥锁方案
:由于保证了互斥性,所以数据一致,且实现简单,只是加了一把锁而已,也没有其他的事情需要操心,所以没有额外的内存消耗,缺点在于有锁的情况,就可能死锁,所以只能串行执行,性能会受到影响逻辑过期方案
:线程读取过程中不需要等待,性能好,有一个额外的线程持有锁去进行重构缓存数据,但是在重构数据完成之前,其他线程只能返回脏数据,且实现起来比较麻烦
解决方案 | 优点 | 缺点 |
---|---|---|
互斥锁 | 没有额外的内存消耗 保证一致性 实现简单 |
线程需要等待,性能受影响 可能有死锁风险 |
逻辑过期 | 线程无需等待,性能较好 |
不保证一致性 有额外内存消耗 实现复杂 |
基于互斥锁解决缓存击穿问题
操作锁的代码
private boolean tryLock(String key) { Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS); //避免返回值为null,我们这里使用了BooleanUtil工具类 return BooleanUtil.isTrue(flag); }
private void unlock(String key) { stringRedisTemplate.delete(key); }
缓存穿透的代码提取成独立的方法,方便以后查看
@Override public Shop queryWithPassThrough(Long id) { //先从Redis中查,这里的常量值是固定的前缀 + 店铺id String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id); //如果不为空(查询到了),则转为Shop类型直接返回 if (StrUtil.isNotBlank(shopJson)) { Shop shop = JSONUtil.toBean(shopJson, Shop.class); return shop; } if (shopjson != null) { return null; } //否则去数据库中查 Shop shop = getById(id); //查不到,则将空值写入Redis if (shop == null) { stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, "", CACHE_NULL_TTL, TimeUnit.MINUTES); return null; } //查到了则转为json字符串 String jsonStr = JSONUtil.toJsonStr(shop); //并存入redis,设置TTL stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr, CACHE_SHOP_TTL, TimeUnit.MINUTES); //最终把查询到的商户信息返回给前端 return shop; }
解决缓存击穿问题
@Override public Result queryById(Long id) { // 缓存穿透 // Shop shop = queryWithPassThrough(id); // 互斥锁解决缓存击穿 Shop shop = queryWithMutex(id); if (shop == null) { return Result.fail("店铺不存在!"); } return Result.ok(shop); } public Shop queryWithMutex(Long id) { // 1.先从Redis中查,这里的常量值是固定的前缀 + 店铺id String shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id); // 2.如果不为空(查询到了),则转为Shop类型直接返回 if (StrUtil.isNotBlank(shopJson)) { Shop shop = JSONUtil.toBean(shopJson, Shop.class); return shop; } if (shopJson != null) { return null; } // 3.实现缓存重建 // 3.1 获取互斥锁 String lockKey = "lock:shop:" + id; Shop shop = null; try { boolean isLock = tryLock(lockKey); // 3.2 判断是否获取成功 if (!isLock) { // 3.3 失败,则休眠并递归重试 Thread.sleep(50); queryWithMutex(id); } // 3.4 成功,根据id查询数据库 shop = getById(id); // 4. 查不到,则将空值写入Redis if (shop == null) { stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, "", CACHE_NULL_TTL, TimeUnit.MINUTES); return null; } // 5.查到了则转为json字符串,并存入redis,设置TTL String jsonStr = JSONUtil.toJsonStr(shop); stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr, CACHE_SHOP_TTL, TimeUnit.MINUTES); } catch (InterruptedException e) { throw new RuntimeException(e); } finally { // 6.释放互斥锁 unlock(lockKey); } // 7.最终把查询到的商户信息返回给前端 return shop; }
基于逻辑过期方式解决缓存击穿问题
新建一个实体类,包含原有数据(用万能的Object)和过期时间,这样对原有的代码没有侵入性
@Data public class RedisData { private LocalDateTime expireTime; private Object data; }
自定义方法,用于向redis写入热点数据
public void saveShop2Redis(Long id, Long expirSeconds) { Shop shop = getById(id); RedisData redisData = new RedisData(); redisData.setData(shop); redisData.setExpireTime(LocalDateTime.now().plusSeconds(expirSeconds)); stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, JSONUtil.toJsonStr(redisData)); }
测试能否写入成功
@SpringBootTest class HmDianPingApplicationTests { @Resource private ShopServiceImpl shopService; @Test void test() { shopService.saveShop2Redis(1L, 1000L); } }
逻辑过期解决缓存击穿正式代码
@Override public Result queryById(Long id) { // 缓存穿透 // Shop shop = queryWithPassThrough(id); // 互斥锁解决缓存击穿 // Shop shop = queryWithMutex(id); // 逻辑过期解决缓存击穿 Shop shop = queryWithLogicalExpire(id); if (shop == null) { return Result.fail("店铺不存在!"); } return Result.ok(shop); } @Override public Shop queryWithLogicalExpire(Long id) { //1. 从redis中查询商铺缓存 String json = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id); //2. 如果未命中,则返回空 if (StrUtil.isBlank(json)) { return null; } //3. 命中,将json反序列化为对象 RedisData redisData = JSONUtil.toBean(json, RedisData.class); //3.1 将data转为Shop对象 JSONObject shopJson = (JSONObject) redisData.getData(); Shop shop = JSONUtil.toBean(shopJson, Shop.class); //3.2 获取过期时间 LocalDateTime expireTime = redisData.getExpireTime(); //4. 判断是否过期 if (LocalDateTime.now().isBefore(LocalDateTime.now())) { //5. 未过期,直接返回商铺信息 return shop; } //6. 过期,尝试获取互斥锁 boolean flag = tryLock(LOCK_SHOP_KEY + id); //7. 获取到了锁 if (flag) { //8. 开启独立线程 CACHE_REBUILD_EXECUTOR.submit(() -> { try { this.saveShop2Redis(id, LOCK_SHOP_TTL); } catch (Exception e) { throw new RuntimeException(e); } finally { unlock(LOCK_SHOP_KEY + id); } }); //9. 直接返回商铺信息 return shop; } //10. 未获取到锁,直接返回商铺信息 return shop; }
缓存工具封装
方法1:将任意Java对象序列化为JSON,并存储到String类型的Key中,并可以设置TTL过期时间
方法2:将任意Java对象序列化为JSON,并存储在String类型的Key中,并可以设置逻辑过期时间,用于处理缓存击穿问题
方法3:根据指定的Key查询缓存,并反序列化为指定类型,利用缓存空值的方式解决缓存穿透问题
方法4:根据指定的Key查询缓存,并反序列化为指定类型,需要利用逻辑过期解决缓存击穿问题
方法5:根据指定的Key查询缓存,并反序列化为指定类型,需要利用互斥锁解决缓存击穿问题
@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; } public void set(String key, Object value, Long time, TimeUnit timeUnit) { stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(value), time, timeUnit); } public void setWithLogicExpire(String key, Object value, Long time, TimeUnit timeUnit) { RedisData redisData = new RedisData(); redisData.setData(value); redisData.setExpireTime(LocalDateTime.now().plusSeconds(timeUnit.toSeconds(time))); stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(redisData)); } 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; } 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; } 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); } }