Redis从入门到精通(四)Redis实战(二)商户查询缓存

↑↑↑请在文章头部下载测试项目原代码↑↑↑

文章目录

    • 前言
    • 4.2 商户查询缓存
      • 4.2.1 缓存介绍
      • 4.2.2 查询商户信息的传统做法
        • 4.2.2.1 接口文档
        • 4.2.2.2 代码实现
        • 4.2.2.3 功能测试
      • 4.2.3 查询商户信息添加Redis缓存
        • 4.2.3.1 逻辑分析
        • 4.2.3.2 代码实现
        • 4.2.3.3 功能测试
      • 4.2.3 数据一致性问题及其解决方案
        • 4.2.3.1 问题分析
        • 4.2.3.2 实现商户信息的双写一致
      • 4.2.4 缓存穿透问题及其解决方案
        • 4.2.4.1 什么是缓存穿透问题
        • 4.2.4.2 缓存穿透问题的解决方案
        • 4.2.4.3 基于缓存空对象解决缓存穿透问题
      • 4.2.5 缓存击穿问题及其解决
        • 4.2.5.1 什么是缓存击穿问题
        • 4.2.5.2 缓存击穿问题的解决方案
        • 4.2.5.3 利用互斥锁解决缓存击穿问题
        • 4.2.5.4 利用逻辑过期解决缓存击穿问题

前言

上一节实现了Redis实战项目的第一个功能:短信登录。项目最初采用session方式实现短信登录,但该方式存在session共享问题,因此改为基于Redis来实现。

Redis从入门到精通(四)Redis实战(一)短信登录

4.2 商户查询缓存

4.2.1 缓存介绍

缓存(Cache),即数据交换的缓存区,俗称的缓存就是指缓存区中的数据。缓存最大的特点就是它运行在内存中,速度快,可以大大降低用户访问并发量带来的服务器读写压力。

但缓存也有不足之处,就是会增加代码复杂度和运营成本:

在实际开发中,会构筑多级缓存来使系统运行速度进一步提升,包括:

  • 浏览器缓存:浏览器在用户磁盘上对最近请求过的文档进行存储,当访问者再次请求这个页面时,浏览器就可以从本地磁盘显示文档,这样就可以加速页面的阅览。。
  • 应用层缓存:例如Tomcat本地缓存或Redis缓存。
  • 数据库缓存:例如MySQL缓存,是指MySQL数据库服务器中的内存区域,用于存储经常访问的数据和查询结果,以提高查询性能和响应时间。。
  • CPU缓存:CPU的L1、L2、L3级缓存。

4.2.2 查询商户信息的传统做法

根据ID查询商户信息,传统做法是直接从数据库查询,并将查询结果返回。

4.2.2.1 接口文档
项目说明
请求方式GET
请求路径/shop/{id}
请求参数id
返回值Shop
4.2.2.2 代码实现

在ShopController类中实现一个queryById()方法,调用IShopService接口的queryShopById()方法:

// com.star.redis.dzdp.controller.ShopController@Slf4j
@RestController
@RequestMapping("/shop")
public class ShopController {@Resourceprivate IShopService shopService;/*** 根据ID查询商户信息* @author hsgx* @since 2024/4/3 11:23* @param id* @return com.star.redis.dzdp.pojo.BaseResult<com.star.redis.dzdp.pojo.Shop>*/@GetMapping("/{id}")public BaseResult<Shop> queryById(@PathVariable Long id) {return shopService.queryShopById(id);}
}

然后在IShopService接口的实现类ShopServiceImpl类中实现queryShopById()方法:

// com.star.redis.dzdp.service.impl.ShopServiceImpl@Slf4j
@Service
@Transactional(rollbackFor = Exception.class)
public class ShopServiceImpl extends ServiceImpl<ShopMapper, Shop> implements IShopService {@Overridepublic BaseResult<Shop> queryShopById(Long id) {log.info("query Shop by id = {}", id);// 查询数据库Shop shop = getById(id);if(shop == null) {return BaseResult.setFail("商户不存在!");}return BaseResult.setOkWithData(shop);}
}
4.2.2.3 功能测试

当id=100时,返回“商户不存在”:

当id=1时,成功获取到商户信息,耗时62ms

4.2.3 查询商户信息添加Redis缓存

4.2.3.1 逻辑分析

通常情况下,该功能的逻辑是在查询数据库之前先查询Redis,如果Redis中存在数据,则直接从Redis中返回数据;如果Redis中没有数据,再查询数据库,并将查询结果保存到Redis中。

4.2.3.2 代码实现

修改ShopServiceImpl类中实现queryShopById()方法,添加查询Redis的逻辑:

// com.star.redis.dzdp.service.impl.ShopServiceImpl@Resource
private StringRedisTemplate stringRedisTemplate;@Override
public BaseResult<Shop> queryShopById(Long id) {log.info("query Shop by id = {}", id);// 1.构建Key,并从Redis中查询商户信息String key = "cache:shop:" + id;String shopJson = stringRedisTemplate.opsForValue().get(key);log.info("get from Redis: Key = {}, Value = {}", key, shopJson);// 2.判断商户信息是否存在if(StrUtil.isNotBlank(shopJson)) {// 3.存在,直接返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return BaseResult.setOkWithData(shop);}// 4.不存在,根据ID查询数据库Shop shop = getById(id);if(shop == null) {return BaseResult.setFail("商户不存在!");}// 5.将商户信息写入RedisstringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop));log.info("set to Redis: Key = {}, Value = {}", key, JSONUtil.toJsonStr(shop));// 6. 返回信息return BaseResult.setOkWithData(shop);
}
4.2.3.3 功能测试

当id=1时,由于此时Redis中还没有数据,所以会从数据库查询数据并保存到Redis。控制台打印信息如下(省略了一些不重要的信息):

query Shop by id = 1
get from Redis: Key = cache:shop:1, Value = null
==>  Preparing: SELECT id,name,type_id,images,area,address,x,y,avg_price,sold,comments,score,open_hours,create_time,update_time FROM tb_shop WHERE id=?
==> Parameters: 1(Long)
<==      Total: 1
set to Redis: Key = cache:shop:1, Value = {"area":"大关","openHours":"10:00-22:00",...省略...,"id":1}

此时可以查询Redis中已经保存了商户的数据:

再次查询id=1的商户信息,由于此时Redis中已经存在数据,所以会直接从Redis中返回。控制台打印信息如下(省略了一些不重要的信息):

query Shop by id = 1
get from Redis: Key = cache:shop:1, Value = {"area":"大关","openHours":"10:00-22:00",...省略...,"id":1}

再比较一下两次查询的性能,第二次查询耗时15ms,比前面直接查询数据库的方式的62ms要快。

4.2.3 数据一致性问题及其解决方案

4.2.3.1 问题分析

如果我们向Redis添加的大量数据,就会导致Redis缓存中的数据过多,为了节约宝贵的内存资源,Redis会对部分数据进行动态更新。 主要有三种方式:

  • 1)内存淘汰

在Redis的配置文件redis.conf中,有两个关于内存淘汰的配置:

# 最大内存限制
maxmemory 512mb
# 当达到最大内存限制时的缓存更新策略
maxmemory-policy noeviction

maxmemory用于配置最大内存限制,当Redis中保存的数据超过该限制时,就会根据maxmemory-policy配置的策略自动淘汰一部分数据。

  • 2)超时剔除

Redis支持单独为每个Key设置有效期,超过有效期后,Redis会自动删除。

  • 3)主动更新

我们还可以手动调用Redis的DEL命令删除数据,通常用于解决缓存和数据库不一致的问题。

Redis缓存中的数据来源于数据库,因此当数据库的数据发生变化时,如果Redis缓存没有同步,就会产生数据一致性问题。

解决数据一致性问题也有三种方案:

  • 1)Cache Aside Pattern:人工编码方式,由开发者在更新完数据库后再去更新缓存,也称之为双写方案
  • 2)Read/Write Through Pattern:缓存与数据库整合为一个服务,由该服务来维护缓存与数据库的数据一致性。
  • 3)Write Behind Caching Pattern:调用者只操作缓存,由其他线程去异步处理数据库实现数据的最终一致。

通常情况下,双写方案是最易实现,且可靠性最好的方案。因此本案例采用的就是双写方案。

下面继续来考虑双写方案的两个问题:

  • 1)无效写操作过多问题

假设需要对数据库的记录进行N次修改。如果每次修改记录后都更新缓存,则需要更新N次缓存,但如果在这N次修改期间并没有另一个用户查询数据,那对缓存来说,只有最后一次更新是有效的,中间的几次更新都是无效的。这就导致了无效写操作较多的问题。

要避免这个问题,可以放弃每次修改记录都更新缓存的方案,而是在修改记录后删除缓存,等待再次查询时再更新缓存。这样就能确保缓存中的数据始终是最新的,且避免多次写操作。

  • 2)操作顺序问题

先修改数据库,再更新缓存?还是先更新缓存,再修改数据库?

答案是先修改数据库,再更新缓存。 原因如下:

4.2.3.2 实现商户信息的双写一致
  • 1)修改ShopServiceImpl类的queryShopById()方法

根据id查询商户时,如果缓存中没有,则查询数据库,再将数据库结果写入缓存并返回。此处将写入缓存这一步,增设超时时间。到时间后商户缓存自动失效,再次查询时自动更新为最新信息。

// com.star.redis.dzdp.service.impl.ShopServiceImpl#queryShopById()// 5.将商户信息写入Redis
// 旧逻辑
// stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop));
// 新逻辑:增设超时时间,30分钟
stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), 30, TimeUnit.MINUTES);
  • 2)实现根据ID修改商户信息功能

接口文档如下:

项目说明
请求方式POST
请求路径/shop/edit
请求参数Shop
返回值

在ShopController类中白那些一个editById()方法,调用IShopService接口的editShopById()方法:

// com.star.redis.dzdp.controller.ShopController/*** 根据ID修改商户信息* @author hsgx* @since 2024/4/3 15:17* @param shop * @return com.star.redis.dzdp.pojo.BaseResult*/
@PostMapping("/edit")
public BaseResult edit(@RequestBody Shop shop) {return shopService.editShopById(shop);
}

然后在IShopService接口的实现类ShopServiceImpl类中编写editShopById()方法:

// com.star.redis.dzdp.service.impl.ShopServiceImpl@Override
public BaseResult editShopById(Shop shop) {log.info("edit Shop by id = {}", shop.toString());if(shop.getId() == null) {return BaseResult.setFail("商户ID不能为空");}// 1.更新数据库记录updateById(shop);// 2.删除缓存Boolean delete = stringRedisTemplate.delete("cache:shop:" + shop.getId());log.info("delete from Redis: Key = {}, result = {}", "cache:shop:" + shop.getId(), delete);return BaseResult.setOk();
}

最后进行功能测试:

调用/shop/1接口获取id=1的商户信息,日志显示从Redis直接返回:

query Shop by id = 1
get from Redis: Key = cache:shop:1, Value = {"area":"大关","openHours":"10:00-22:00",...省略...,"id":1}

调用/shop/edit接口修改id=1的商户信息,日志显示先修改数据库记录后删除Redis缓存:

edit Shop by id = Shop(id=1, name=null, typeId=null, images=null, area=修改后的area, address=null, x=null, y=null, avgPrice=null, sold=null, comments=null, score=null, openHours=null, createTime=null, updateTime=null, distance=null)
==>  Preparing: UPDATE tb_shop SET area=? WHERE id=?
==> Parameters: 修改后的area(String), 1(Long)
<==    Updates: 1
delete from Redis: Key = cache:shop:1, result = true

再次调用/shop/1接口获取id=1的商户信息,日志显示从数据库查询后再存入Redis,且数据是最新的:

query Shop by id = 1
get from Redis: Key = cache:shop:1, Value = null
==>  Preparing: SELECT id,name,type_id,images,area,address,x,y,avg_price,sold,comments,score,open_hours,create_time,update_time FROM tb_shop WHERE id=?
==> Parameters: 1(Long)
<==      Total: 1
set to Redis: Key = cache:shop:1, Value = {"area":"修改后的area","openHours":"10:00-22:00",...省略...,"id":1}

4.2.4 缓存穿透问题及其解决方案

4.2.4.1 什么是缓存穿透问题

查询商户信息时,目前的做法仍然存在漏洞,即当id=100时,Redis和数据库都没有数据,程序最终会操作数据库。那如果有大量id=100的查询请求,每次都会去查询数据库,Redis缓存就相当于摆设了。

这就是缓存穿透问题,即客户端请求的数据在缓存中和数据库中都不存在,这些请求会穿透缓存,直击数据库,给数据库造成压力。

4.2.4.2 缓存穿透问题的解决方案

常见的解决缓存穿透问题的方案有两种:缓存空对象、布隆过滤。

  • 1)缓存空对象

服务端接收到查询请求后,如果Redis和数据库都不存在,也将这个数据存入Redis,只是其Value值设置为空字符串""。那么下次查询这个不存在的数据时,在Redis这里就可以知道数据不存在了,而不用继续访问数据库。

缓存空对象的优点在于实现简单、维护方便;缺点在于有额外的内存消耗。

  • 2)布隆过滤

布隆过滤是指采用哈希思想来解决这个问题,通过一个庞大的二进制数组,利用哈希思想判断当前要查询的数据是否存在。如果布隆过滤器判断存在,则放行,这个请求会去访问Redis或数据库;如果布隆过滤器判断这个数据不存在,则直接返回不存在。

布隆过滤的优点在于节约内存空间,没有多余的Key;缺点是布隆过滤器走的是哈希思想,可能存在误判。

综合考虑,本案例采用缓存空对象的方案。

4.2.4.3 基于缓存空对象解决缓存穿透问题

修改ShopServiceImpl类的queryShopById方法:

// com.star.redis.dzdp.service.impl.ShopServiceImpl#queryShopById()// 2.判断商户信息是否存在
if(StrUtil.isNotBlank(shopJson)) {// 3.存在,直接返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return BaseResult.setOkWithData(shop);
} else if("".equals(shopJson)) {// 新增逻辑:如果保存了空字符串,则说明是商户信息不存在,直接返回不存在return BaseResult.setFail("商户不存在!");
}// 4.不存在,根据ID查询数据库
Shop shop = getById(id);
// 旧逻辑:shop为空时直接返回不存在
// 新逻辑:要将字符串写入Redis,因此这里不直接返回
// if(shop == null) {
//     return BaseResult.setFail("商户不存在!");
// }// 5.将商户信息写入Redis
// 新逻辑:如果商户信息为空,则将空字符串写入Redis
stringRedisTemplate.opsForValue().set(key,shop != null ? JSONUtil.toJsonStr(shop) : "",30, TimeUnit.MINUTES);

接下来进行功能测试:调用/shop/100接口获取id=100的商户信息,日志显示将空字符串写入了Redis:

query Shop by id = 100
get from Redis: Key = cache:shop:100, Value = null
==>  Preparing: SELECT id,name,type_id,images,area,address,x,y,avg_price,sold,comments,score,open_hours,create_time,update_time FROM tb_shop WHERE id=?
==> Parameters: 100(Long)
<==      Total: 0
set to Redis: Key = cache:shop:100, Value = null

查看Redis中保存的数据:

再次调用/shop/100接口获取id=100的商户信息,日志显示从Redis中获取到了空值,注解返回商户不存在:

query Shop by id = 100
get from Redis: Key = cache:shop:100, Value = 

4.2.5 缓存击穿问题及其解决

4.2.5.1 什么是缓存击穿问题

缓存击穿问题也叫热点Key问题,就是一个被高并发访问并且缓存重建业务较复杂的Key突然失效了,大量的请求击穿缓存到达数据库,给数据库造成压力。 例如:

如上图所示,线程1查询缓存未命中,然后继续查询数据库并重建缓存数据,但由于重建缓存数据业务复杂,没等重建完成,线程2、3、4就来查询缓存了,线程2、3、4都不能从缓存中查到数据,转而去查数据库。最终结果是4个线程都访问了数据库,给数据库造成压力。

4.2.5.2 缓存击穿问题的解决方案

解决方案一:互斥锁

如上图所示,线程1查询缓存未命中,然后会获取互斥锁,获取到了锁再继续查询数据库并重建缓存数据,最后释放锁。而此时线程2查询缓存未命中,也去获取互斥锁,但锁只能一个线程使用,所以会获取失败,转而进入休眠状态,不断地尝试查询缓存和获取锁这两步;等线程1重建缓存完成并释放锁后,线程2获取到互斥锁,就能跳出休眠状态,从缓冲中获取到数据了。

解决方案二:逻辑过期

如上图所示,逻辑过期方案的要点是不对key设置过期时间,而是将过期时间设置在Value值中。 假设线程1查询缓存,发现逻辑时间已经过期,则开启一个新的线程2并直接返回过期的数据。线程2获取互斥锁,去查询数据库和重构缓存数据,完成后释放锁。假设线程3过来访问,由于线程2持有着锁,所以线程3无法获得锁,线程3也直接返回过期数据,只有等到线程2重建缓存数据完成后,才能返回正确的数据。

两种解决方案各有优缺点:

互斥锁:由于保证了互斥性,所以数据一致,且实现简单,仅仅只需要加一把锁,没有额外的内存消耗,缺点在于有锁就有死锁问题的发生,且只能串行执行,性能会受到影响。
逻辑过期:线程读取过程中不需要等待,性能好,有一个额外的线程持有锁去进行重构数据,但是在重构数据完成前,其他的线程只能返回之前的脏数据,且实现起来麻烦

4.2.5.3 利用互斥锁解决缓存击穿问题

如上图所示,要利用互斥锁解决缓存击穿问题,可以在缓存未命中时,尝试获取互斥锁,只有获取到了互斥锁,才能查询数据库并将查询结果写入Redis;而没有获取到互斥锁时,则进行休眠,并重试查询缓存。

在持有互斥锁的线程完成查询数据库并将查询结果写入Redis的动作之前,其他没有获得互斥锁的线程不断重复地从Redis拿数据,直到互斥锁被释放后,才能从Redis拿到数据。

下面正式进行代码编写。首先要对互斥锁进行设计:

Redis的String类型有一个SETNX方法,该方法会尝试添加一个String类型的键值对,前提是这个key不存在,否则不执行。我们可以利用这个方法来获取互斥锁,如果调用该方法成功,说明Key不存在,获取互斥锁成功;调用该方法失败,说明Key已存在,获取互斥锁失败。

在ShopServiceImpl类中编写获取互斥锁的tryLock()方法,以及释放锁的unLock()方法:

// com.star.redis.dzdp.service.impl.ShopServiceImpl/*** 获取互斥锁* @author hsgx* @since 2024/4/3 17:19* @param key* @return boolean*/
private boolean tryLock(String key) {Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(key, "1", 10, TimeUnit.SECONDS);return BooleanUtil.isTrue(flag);
}/*** 释放锁* @author hsgx* @since 2024/4/3 17:20* @param key* @return void*/
private void unLock(String key) {stringRedisTemplate.delete(key);
}

接着在IShopService接口中定义一个queryShopByIdWithLock()方法,并在其实现类ShopServiceImpl中具体实现,功能仍然是根据ID查询商户信息,只是添加了互斥锁:

// com.star.redis.dzdp.service.impl.ShopServiceImplpublic BaseResult<Shop> queryShopByIdWithLock(Long id) {log.info("query Shop by id = {}", id);// 1.构建Key,并从Redis中查询商户信息String key = "cache:shop:" + id;String shopJson = stringRedisTemplate.opsForValue().get(key);log.info("get from Redis: Key = {}, Value = {}", key, shopJson);// 2.判断商户信息是否存在if(StrUtil.isNotBlank(shopJson)) {// 存在,直接返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return BaseResult.setOkWithData(shop);} else if("".equals(shopJson)) {// 如果保存了空字符串,则说明是商户信息不存在,直接返回不存在return BaseResult.setFail("商户不存在!");}// 3.使用互斥锁方案解决缓存击穿问题String lockKey = "lock:shop:" + id;Shop shop = null;try {// 尝试获取互斥锁boolean isLock = tryLock(lockKey);log.info("isLock = {}", isLock);if(!isLock) {// 没有获取到互斥锁,则休眠重试log.info("Retry queryShopByIdWithLock()...");Thread.sleep(50);return queryShopByIdWithLock(id);}// 获取到了互斥锁,则根据ID查询数据,并重构缓存数据shop = getById(id);if(shop == null) {// 商户不存在,保存空字符串stringRedisTemplate.opsForValue().set(key, "", 30, TimeUnit.MINUTES);log.info("set to Redis: Key = {}, Value = \"\"", key);return BaseResult.setFail("商户不存在!");} else {stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), 30, TimeUnit.MINUTES);log.info("set to Redis: Key = {}, Value = {}", key, JSONUtil.toJsonStr(shop));}} catch (Exception e) {e.printStackTrace();} finally {// 释放锁unLock(lockKey);}return BaseResult.setOkWithData(shop);
}

然后修改ShopController类中的调用方法:

// com.star.redis.dzdp.controller.ShopController@GetMapping("/{id}")
public BaseResult<Shop> queryById(@PathVariable Long id) {//return shopService.queryShopById(id);// 使用互斥锁解决缓存击穿问题return shopService.queryShopByIdWithLock(id);
}

修改完毕后,进行功能测试:首先在shop = getById(id);这一行代码上打一个断点,用于模拟重建缓存数据的时间很久。

然后调用/shop/102接口获取id=102的商户信息,日志显示线程5从Redis中没有获取到数据,并获取互斥锁成功,进入查询数据库和重建缓存的逻辑,停在了断点处:

[http-nio-8081-exec-5] query Shop by id = 102
[http-nio-8081-exec-5] get from Redis: Key = cache:shop:102, Value = null
[http-nio-8081-exec-5] tryLock key = lock:shop:102
[http-nio-8081-exec-5] isLock = true

接着再次调用/shop/102接口获取id=102的商户信息,日志显示线程6从Redis中没有获取到数据,并获取互斥锁失败,进入重试逻辑,再次调用queryShopByIdWithLock()方法:

[http-nio-8081-exec-6] query Shop by id = 102
[http-nio-8081-exec-6] get from Redis: Key = cache:shop:102, Value = null
[http-nio-8081-exec-6] tryLock key = lock:shop:102
[http-nio-8081-exec-6] isLock = false
[http-nio-8081-exec-6] Retry queryShopByIdWithLock()...

此时放开断点,线程5继续执行,查询数据库信息,并将查询结果写入Redis,最后释放锁:

[http-nio-8081-exec-5] ==>  Preparing: SELECT id,name,type_id,images,area,address,x,y,avg_price,sold,comments,score,open_hours,create_time,update_time FROM tb_shop WHERE id=?
[http-nio-8081-exec-5] ==> Parameters: 102(Long)
[http-nio-8081-exec-5] <==      Total: 0
[http-nio-8081-exec-5] set to Redis: Key = cache:shop:102, Value = ""

锁释放后,线程6已可以从Redis中拿到数据并返回结果:

[http-nio-8081-exec-6] query Shop by id = 102
[http-nio-8081-exec-6] get from Redis: Key = cache:shop:102, Value = 

至此,基于互斥锁的方案测试完成。

4.2.5.4 利用逻辑过期解决缓存击穿问题

由上图可知,当查询缓存未命中时,则直接返回空;如果命中了,则将缓存数据中的Value值取出,判断Value值中保存的时间是否过期,如果没有过期,则直接返回缓存数据;如果过期了,则获取互斥锁,并开启一个独立的线程后直接返回过期数据。

独立线程负责查询数据库并更新缓存数据。而其他线程在获得过期数据后,由于无法获取互斥锁,也直接返回过期数据。

下面开始编写代码。由于要在Value值中保存过期时间,我们首先要重新定义一个保存到Redis的实体类。

// com.star.redis.dzdp.pojo.RedisData@Data
public class RedisData {private Date expireTime;private Object data;
}

接着在IShopService接口中定义一个queryShopByIdWithExpire()方法,并在其实现类ShopServiceImpl中具体实现,功能仍然是根据ID查询商户信息,只是添加了逻辑过期:

// com.star.redis.dzdp.service.impl.ShopServiceImplprivate static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);@Override
public BaseResult<Shop> queryShopByIdWithExpire(Long id) {log.info("query Shop by id = {}", id);// 1.构建Key,并从Redis中查询商户信息String key = "cache:shop:" + id;String shopJson = stringRedisTemplate.opsForValue().get(key);log.info("get from Redis: Key = {}, Value = {}", key, shopJson);// 2.商户信息不存在,直接返回if(StrUtil.isBlank(shopJson)) {return BaseResult.setFail("商户不存在!");}// 3.商户信息存在,先反序列化为Java对象RedisData redisData = JSONUtil.toBean(shopJson, RedisData.class);Date expireTime = redisData.getExpireTime();Shop shop = JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);// 4.判断是否过期if(expireTime.after(new Date())) {// 没过期,直接返回数据return BaseResult.setOkWithData(shop);}// 5.已过期,则尝试获取互斥锁String lockKey = "lock:shop:" + id;try {boolean isLock = tryLock(lockKey);log.info("isLock = {}", isLock);if(!isLock) {// 没有获取到互斥锁,则直接返回过期数据return BaseResult.setOkWithData(shop);}// 获取到了互斥锁,则开启一个新的线程log.info("create a new thread ...");CACHE_REBUILD_EXECUTOR.submit(() -> {log.info("a new thread begin...");// 查询数据库Shop newShop = getById(id);// 写入RedisRedisData newRedisDate = new RedisData();newRedisDate.setData(newShop);long expire = System.currentTimeMillis() + 30 * 60 * 1000;newRedisDate.setExpireTime(new Date(expire));stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(newRedisDate));log.info("set to Redis: Key = {}, Value = {}", key, JSONUtil.toJsonStr(newRedisDate));// 释放锁unLock(lockKey);log.info("a new thread end...");});} catch (Exception e) {e.printStackTrace();}// 当前线程直接返回过期数据return BaseResult.setOkWithData(shop);
}

然后修改ShopController类中的调用方法:

// com.star.redis.dzdp.controller.ShopController@GetMapping("/{id}")
public BaseResult<Shop> queryById(@PathVariable Long id) {// return shopService.queryShopById(id);// 使用互斥锁解决缓存击穿问题// return shopService.queryShopByIdWithLock(id);// 使用逻辑过期解决缓存击穿问题return shopService.queryShopByIdWithExpire(id);
}

由于在queryShopByIdWithExpire()方法中,只要Redis未命中就直接返回不存在,因此这种方式需要进行初始化,也就是将数据库的商户信息同步一次到Redis中。

假设现在初始化过了,在Redis中有这样一条数据:

然后我们在线程内部添加一行代码Thread.sleep(30 * 1000);,用于模拟新线程重建缓存数据的时间很久。

接着调用/shop/2接口获取id=2的商户信息,日志显示线程1从Redis中没有获取到了过期数据,并获取互斥锁成功,然后创建新线程:

[http-nio-8081-exec-1] query Shop by id = 2
[http-nio-8081-exec-1] get from Redis: Key = cache:shop:2, Value = {"data":{"area":"拱宸桥/上塘","openHours":"11:30-03:00",...省略...,"id":2},"expireTime":1640170813000}
[http-nio-8081-exec-1] tryLock key = lock:shop:2
[http-nio-8081-exec-1] isLock = true
[http-nio-8081-exec-1] create a new thread ...

然后新线程[pool-1-thread-1]进入30s睡眠,模拟耗时很长。 此时一个新的请求过来,线程2开始执行,日志显示线程2从Redis拿到了过期数据,但获取互斥锁失败,直接返回过期数据:

[pool-1-thread-1]  a new thread begin...
[http-nio-8081-exec-2] query Shop by id = 2
get from Redis: Key = cache:shop:2, Value = {"data":{"area":"拱宸桥/上塘","openHours":"11:30-03:00",...省略...,"id":2},"expireTime":1640170813000}
[http-nio-8081-exec-2] tryLock key = lock:shop:2
[http-nio-8081-exec-2] isLock = false

新线程[pool-1-thread-1]休眠结束,查询数据库,并将查询结果更新到Redis,最后释放互斥锁:

[pool-1-thread-1] ==>  Preparing: SELECT id,name,type_id,images,area,address,x,y,avg_price,sold,comments,score,open_hours,create_time,update_time FROM tb_shop WHERE id=?
[pool-1-thread-1] ==> Parameters: 2(Long)
[pool-1-thread-1] <==      Total: 1
[pool-1-thread-1] set to Redis: Key = cache:shop:2, Value = {"data":{"area":"拱宸桥/上塘","openHours":"11:30-03:00",...省略...,"id":2},"expireTime":1712234901457}
[pool-1-thread-1] unLock key = lock:shop:2
[pool-1-thread-1] a new thread end...

至此,基于逻辑过期的方案也测试完成。

本节完,更多内容请查阅分类专栏:Redis从入门到精通

感兴趣的读者还可以查阅我的另外几个专栏:

  • SpringBoot源码解读与原理分析(已完结)
  • MyBatis3源码深度解析(已完结)
  • 再探Java为面试赋能(持续更新中…)

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/792776.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

软考之零碎片段记录(五)

一、设计模式 1.策略模式 可在运行时改变行为和算法。这种类型的设计模式属于行为模式。使得代码更加灵活和可维护。 2. 命令模式 将请求封装成独立的对象并通过参数传递。属于行为模式。 3. 观察者模式 当对象状态改变时&#xff0c;依赖于它的对象都会被通知并进行更新…

Java操作hdfs,总是报ClosedChannelException

现象 public boolean uploadFile(MultipartFile file, String dst) {try {long start System.currentTimeMillis();// 创建Hadoop配置对象Configuration config new Configuration();config.set("fs.defaultFS", hdfsUri);Path dstPath new Path(ROOT_PATH dst)…

【MATLAB源码-第177期】基于matlab的蜘蛛蜂优化算法(SWO)无人机三维路径规划,输出做短路径图和适应度曲线

操作环境&#xff1a; MATLAB 2022a 1、算法描述 蜘蛛蜂优化算法&#xff08;Spider Wasp Optimization, SWO&#xff09;是一种启发式算法&#xff0c;它受到自然界中蜘蛛和蜂这两种生物的行为模式启发而开发。这一算法主要模拟了蜘蛛捕食与蜂群社会行为之间的相互作用&…

Mac brew 安装软件

Mac brew 安装软件 homebrew 速度慢 将brew 切换到国内镜像源 # 速度一般 # 步骤一 cd "$(brew --repo)" git remote set-url origin https://mirrors.tuna.tsinghua.edu.cn/git/homebrew/brew.git# 步骤二 cd "$(brew --repo)/Library/Taps/homebrew/homebr…

网络以太网之(1)基础概念

网络以太网之(1)基础概念 Author: Once Day Date: 2024年4月1日 一位热衷于Linux学习和开发的菜鸟&#xff0c;试图谱写一场冒险之旅&#xff0c;也许终点只是一场白日梦… 漫漫长路&#xff0c;有人对你微笑过嘛… 全系列文档可参考专栏&#xff1a;通信网络技术_Once-Day的…

C语言-----数据在内存中的存储(1)

1.整数在内存中的存储 我们之前就了解过整数的二进制写法分别有3种&#xff0c;分别为原码&#xff0c;反码&#xff0c;补码。整型在内存中存储的是补码。 原码&#xff0c;反码&#xff0c;补码都有自己的符号位和数值位&#xff0c;符号位为1时&#xff0c;则表示负数&…

os模块篇(十四)

文章目录 os.renames(old, new)os.replace(src, dst, *, src_dir_fdNone, dst_dir_fdNone)os.rmdir(path, *, dir_fdNone)os.scandir(path.)os.stat(path, *, dir_fdNone, follow_symlinksTrue)os.statvfs(path) os.renames(old, new) os.renames(old, new) 是 Python 的 os 模…

一些常见的Prometheus+Grafana问题和答案:

什么是Prometheus&#xff1f;它的主要功能是什么&#xff1f; Prometheus是一个开源的系统监控和报警工具。它通过收集和存储时间序列数据&#xff0c;提供了强大的查询语言和灵活的报警规则&#xff0c;可以帮助监控和分析系统的性能指标。 Prometheus的数据模型是什么样的…

LLM记录1

LLM的知识库问答有3种实现路径&#xff1a;RAG 或 微调&#xff0c;或两者结合。 RAG&#xff1a;低成本易部署&#xff0c;适用于知识会更新的场景&#xff0c;但知识内容多的情况下&#xff0c;检索成本会变高。微调&#xff1a;算力成本高&#xff0c;微调效果不稳定&#x…

全量知识系统 程序详细设计之 “起点”(递归原始版本)

原文 以下是对全知系统程序详细设计的设计起点的考虑。 关于“程序program” 数据模式--“程序”的基础--数型&#xff08;构造型&#xff09;&#xff1a;数值型、数字型和数据型 。 其中&#xff0c; 1其程序模式--结构化或自动化&#xff08;描述了“数据”的关系型rel…

【Docker笔记05】【网络模式】

一、前言 本系列是根据 B 站 尚硅谷 Docker 视频 学习记录笔记。因为没有视频课件&#xff0c;部分内容摘自 https://www.yuque.com/tmfl/cloud/dketq0。 本系列仅为自身学习笔记记录使用&#xff0c;记录存在偏差&#xff0c;推荐阅读原视频内容或本文参考笔记。 二、简单介…

靠谱的wordpress建站公司怎么选 建网站避坑指南

在选择WordPress建站公司时&#xff0c;查看其建站案例作品是非常重要的。这确实是一个可以直接反映公司实力和信誉的方面。神马都是浮云&#xff0c;作品给力才行。以下是一些建议&#xff0c;帮助您更好地评估一个WordPress建站公司是否靠谱&#xff1a; 1. 查看案例的真实性…

通用开发技能系列:Authentication、OAuth、JWT 认证策略

云原生学习路线导航页&#xff08;持续更新中&#xff09; 本文是 通用开发技能系列 文章&#xff0c;主要对编程通用技能 Authentication、OAuth、JWT 认证策略 进行学习 1.Basic Authentication认证 每个请求都需要将 用户名密码 进行base64编码后&#xff0c;放在请求头的A…

Vaadin框架是如何处理前后端交互的?列举几个Vaadin中常用的UI组件,并描述它们的作用。如何使用Vaadin的布局管理器来构建复杂的用户界面?

Vaadin框架是如何处理前后端交互的&#xff1f; Vaadin框架处理前后端交互的方式主要基于服务端渲染和事件驱动的编程模型。以下是具体的处理过程&#xff1a; 服务端渲染&#xff1a;Vaadin应用程序的UI组件是在服务器端创建和渲染的。当用户在浏览器中访问应用程序时&#x…

基于隐私保护的可追踪可撤销密文策略属性加密方案论文阅读

论文是2022年发表的A Traceable and Revocable Ciphertext-Policy Attribute-based Encryption Scheme Based on Privacy Protection 摘要 本篇论文提出了一种具有用户撤销、白盒追踪、策略策略隐藏功能的CP-ABE方案。在该方案中密文被分为两个部分&#xff1a;第一个部分是和…

算法训练营30天|LeetCode 332.重新安排行程 51.N皇后 37.解数独

LeetCode 332.重新安排行程 题目链接&#xff1a; LeetCode 332.重新安排行程 代码&#xff1a; class Solution { public:unordered_map<string, map<string, int>> targets;bool backtracking(int ticketnum, vector<string>&result){if(result.si…

基于springboot实现教师人事档案管理系统项目【项目源码+论文说明】计算机毕业设计

基于springboot实现在线商城系统演示 摘要 现代经济快节奏发展以及不断完善升级的信息化技术&#xff0c;让传统数据信息的管理升级为软件存储&#xff0c;归纳&#xff0c;集中处理数据信息的管理方式。本ONLY在线商城系统就是在这样的大环境下诞生&#xff0c;其可以帮助管理…

第六期丨酷雷曼无人机技能培训

第6期无人机技能提升培训 盼望着盼望着&#xff0c;第六期无人机技能提升培训会终于如期和大家见面了。 2024年1月1日&#xff0c;国务院、中央军事委员会颁布《无人驾驶航空器飞行管理暂行条例》&#xff0c;对民用无人机飞行活动实施更为严格的规范约束&#xff0c;越来越多…

阿里云服务器安装Java开发环境最佳实践

服务器环境安装 环境依赖服务器配置配置SSH登录打开安全配置端口远程连接配置秘钥 Linux服务器常用指令向远程服务器传送文件systemctl 相关 安装MySql安装步骤step1 检查并清除以前的mysql相关文件step2 安装step3 MySQL参数配置step4 设置开机启动step5 初始化数据库step6配置…

ABAP开发中常用弹窗的应用详解

在ABAP程序设计中为提示和交互的需要会经常用到弹窗&#xff0c; 所谓弹窗就是弹出一个框&#xff0c;告诉用户什么事情、需要确认什么、或者让用户输入什么内容等等&#xff0c;它价值在于通过提示、提醒、警告&#xff0c;帮助用户顺利完成业务流程中的必要操作或给用户提供实…