03、Redis实战:商户查询缓存、缓存更新策略、缓存穿透、缓存雪崩、缓存击穿

2、商户查询缓存

2.1 什么是缓存?

  • 什么是缓存?

    • 就像自行车,越野车的避震器
  • 举个例子:越野车,山地自行车,都拥有"避震器",防止车体加速后因惯性,在酷似"U"字母的地形上飞跃,硬着陆导致的损害,像个弹簧一样;

  • 同样,实际开发中,系统也需要"避震器",防止过高的数据访问猛冲系统,导致其操作线程无法及时处理信息而瘫痪;

  • 这在实际开发中对企业讲,对产品口碑,用户评价都是致命的;所以企业非常重视缓存技术;

  • 缓存(Cache),就是数据交换的缓冲区,俗称的缓存就是缓冲区内的数据,一般从数据库中获取,存储于本地代码(例如:

1:Static final ConcurrentHashMap<K,V> map = new ConcurrentHashMap<>(); 本地用于高并发例2:static final Cache<K,V> USER_CACHE = CacheBuilder.newBuilder().build(); 用于redis等缓存例3:Static final Map<K,V> map =  new HashMap(); 本地缓存
  • 由于其被Static修饰,所以随着类的加载而被加载到内存之中,作为本地缓存,由于其又被final修饰,所以其引用(例3:map)和对象(例3:new HashMap())之间的关系是固定的,不能改变,因此不用担心赋值(=)导致缓存失效;
2.1.1 为什么要使用缓存

一句话:因为速度快,好用

缓存数据存储于代码中,而代码运行在内存中,内存的读写性能远高于磁盘,缓存可以大大降低用户访问并发量带来的服务器读写压力

实际开发过程中,企业的数据量,少则几十万,多则几千万,这么大数据量,如果没有缓存来作为"避震器",系统是几乎撑不住的,所以企业会大量运用到缓存技术;

但是缓存也会增加代码复杂度和运营的成本:

2.1.2 如何使用缓存

实际开发中,会构筑多级缓存来使系统运行速度进一步提升,例如:本地缓存与redis中的缓存并发使用

浏览器缓存:主要是存在于浏览器端的缓存

**应用层缓存:**可以分为tomcat本地缓存,比如之前提到的map,或者是使用redis作为缓存

**数据库缓存:**在数据库中有一片空间是 buffer pool,增改查数据都会先加载到mysql的缓存中

**CPU缓存:**当代计算机最大的问题是 cpu性能提升了,但内存读写速度没有跟上,所以为了适应当下的情况,增加了cpu的L1,L2,L3级的缓存

2.2 添加商户缓存

在我们查询商户信息时,我们是直接操作从数据库中去进行查询的,大致逻辑是这样,直接查询数据库那肯定慢咯,所以我们需要增加缓存

@GetMapping("/{id}")
public Result queryShopById(@PathVariable("id") Long id) {//这里是直接查询数据库return shopService.queryById(id);
}
2.2.1 、缓存模型和思路

标准的操作方式就是查询数据库之前先查询缓存,如果缓存数据存在,则直接从缓存中返回,如果缓存数据不存在,再查询数据库,然后将数据存入redis。

1653322097736

2.1.2、代码如下

业务逻辑我们写到Service中,需要在Service层创建这个queryById方法,然后去ServiceImpl中实现

Controller:

@GetMapping("/{id}")
public Result queryShopById(@PathVariable("id") Long id) {return shopService.queryById(id);
}

Service:

public interface IShopService extends IService<Shop> {Result queryById(Long id);
}

ServiceImpl:

@Override
public Result queryById(Long id) {//先从Redis中查,这里的常量值是固定的前缀 + 店铺idString 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);//并存入redisstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr);//最终把查询到的商户信息返回给前端return Result.ok(shop);
}
2.1.3、趁热打铁
  • 完成了商户数据缓存之后,我们尝试做一下商户类型数据缓存

    业务逻辑依旧是写在Service中

controller

@GetMapping("list")
public Result queryTypeList() {return typeService.queryList();
}

service

public interface IShopTypeService extends IService<ShopType> {Result queryList();
}
  • serviceImpl

  • 整体代码都是类似的,前面只需要将单个店铺信息从JSON和Bean之间相互转换

  • 这里只不过是将查询到的多个店铺类型信息从JSON和Bean之间相互转换,只是多了一个foreach循环

    @Override
    public Result queryList() {//先从Redis中查,这里的常量值是固定前缀 + 店铺id,0,-1代表所有List<String> shopTypes =stringRedisTemplate.opsForList().range(CACHE_SHOP_TYPE_KEY, 0, -1);//如果不为空(查询到了),则转为ShopType类型直接返回if (!shopTypes.isEmpty()) {List<ShopType> tmp = new ArrayList<>();for (String types : shopTypes) {ShopType shopType = JSONUtil.toBean(types, ShopType.class);tmp.add(shopType);}return Result.ok(tmp);}//否则去数据库中查List<ShopType> tmp = query().orderByAsc("sort").list();if (tmp == null){return Result.fail("店铺类型不存在!!");}//查到了转为json字符串,存入redisfor (ShopType shopType : tmp) {String jsonStr = JSONUtil.toJsonStr(shopType);shopTypes.add(jsonStr);}stringRedisTemplate.opsForList().leftPushAll(CACHE_SHOP_TYPE_KEY,shopTypes);//最终把查询到的商户分类信息返回给前端return Result.ok(tmp);
    }
    
    • @Override
      public Result queryList() {// 先从Redis中查,这里的常量值是固定前缀 + 店铺idList<String> shopTypes =stringRedisTemplate.opsForList().range(CACHE_SHOP_TYPE_KEY, 0, -1);// 如果不为空(查询到了),则转为ShopType类型直接返回if (!shopTypes.isEmpty()) {List<ShopType> tmp = shopTypes.stream().map(type -> JSONUtil.toBean(type, ShopType.class)).collect(Collectors.toList());return Result.ok(tmp);}// 否则去数据库中查List<ShopType> tmp = query().orderByAsc("sort").list();if (tmp == null){return Result.fail("店铺类型不存在!!");}// 查到了转为json字符串,存入redisshopTypes = tmp.stream().map(type -> JSONUtil.toJsonStr(type)).collect(Collectors.toList());stringRedisTemplate.opsForList().leftPushAll(CACHE_SHOP_TYPE_KEY,shopTypes);// 最终把查询到的商户分类信息返回给前端return Result.ok(tmp);
      }
      

2.3缓存更新策略

缓存更新是redis为了节约内存而设计出来的一个东西,主要是因为内存数据宝贵,当我们向redis插入太多数据,此时就可能会导致缓存中的数据过多,所以redis会对部分数据进行更新,或者把他叫为淘汰更合适。

**内存淘汰:**redis自动进行,当redis内存达到咱们设定的max-memery的时候,会自动触发淘汰机制,淘汰掉一些不重要的数据(可以自己设置策略方式)

**超时剔除:**当我们给redis设置了过期时间ttl之后,redis会将超时的数据进行删除,方便咱们继续使用缓存

**主动更新:**我们可以手动调用方法把缓存删掉,通常用于解决缓存和数据库不一致问题

1653322506393

2.3.1 、数据库缓存不一致解决方案:

由于我们的缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,此时就会有一致性问题存在,其后果是:

用户使用缓存中的过时数据,就会产生类似多线程数据安全问题,从而影响业务,产品口碑等;怎么解决呢?有如下几种方案

Cache Aside Pattern 人工编码方式:缓存调用者在更新完数据库后再去更新缓存,也称之为双写方案

Read/Write Through Pattern : 由系统本身完成,数据库与缓存的问题交由系统本身去处理

Write Behind Caching Pattern :调用者只操作缓存,其他线程去异步处理数据库,实现最终一致

1653322857620

2.3.2 、数据库和缓存不一致采用什么方案

综合考虑使用方案一,但是方案一调用者如何处理呢?这里有几个问题

操作缓存和数据库时有三个问题需要考虑:

如果采用第一个方案,那么假设我们每次操作数据库后,都操作缓存,但是中间如果没有人查询,那么这个更新动作实际上只有最后一次生效,中间的更新动作意义并不大,我们可以把缓存删除,等待再次查询时,将缓存中的数据加载出来

  • 删除缓存还是更新缓存?

    • 更新缓存:每次更新数据库都更新缓存,无效写操作较多
    • 删除缓存:更新数据库时让缓存失效,查询时再更新缓存
  • 如何保证缓存与数据库的操作的同时成功或失败?

    • 单体系统,将缓存与数据库操作放在一个事务
    • 分布式系统,利用TCC等分布式事务方案

应该具体操作缓存还是操作数据库,我们应当是先操作数据库,再删除缓存,原因在于,如果你选择第一种方案,在两个线程并发来访问时,假设线程1先来,他先把缓存删了,此时线程2过来,他查询缓存数据并不存在,此时他写入缓存,当他写入缓存后,线程1再执行更新动作时,实际上写入的就是旧的数据,新的数据被旧数据覆盖了。

  • 先操作缓存还是先操作数据库?
    • 先删除缓存,再操作数据库
      • 删除缓存的操作很快,但是更新数据库的操作相对较慢,如果此时有一个线程2刚好进来查询缓存,由于我们刚刚才删除缓存,所以线程2需要查询数据库,并写入缓存,但是我们更新数据库的操作还未完成,所以线程2查询到的数据是脏数据,出现线程安全问题
    • 先操作数据库,再删除缓存
      • 线程1在查询缓存的时候,缓存TTL刚好失效,需要查询数据库并写入缓存,这个操作耗时相对较短(相比较于上图来说),但是就在这么短的时间内,线程2进来了,更新数据库,删除缓存,但是线程1虽然查询完了数据(更新前的旧数据),但是还没来得及写入缓存,所以线程2的更新数据库与删除缓存,并没有影响到线程1的查询旧数据,写入缓存,造成线程安全问题
  • 虽然这二者都存在线程安全问题,但是相对来说,后者出现线程安全问题的概率相对较低,所以我们最终采用后者先操作数据库,再删除缓存的方案

1653323595206

2.4 实现商铺和缓存与数据库双写一致

核心思路如下:

  • 修改ShopController中的业务逻辑,满足下面的需求:

    1. 根据id查询店铺时,如果缓存未命中,则查询数据库,将数据库结果写入缓存,并设置超时时间

    2. 根据id修改店铺时,先修改数据库,再删除缓存

修改重点代码1:修改ShopServiceImpl的queryById方法

设置redis缓存时添加过期时间

@Override
public Result queryById(Long id) {//先从Redis中查,这里的常量值是固定的前缀 + 店铺idString 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,设置TTLstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr,CACHE_SHOP_TTL, TimeUnit.MINUTES);//最终把查询到的商户信息返回给前端return Result.ok(shop);
}

修改重点代码2

代码分析:通过之前的淘汰,我们确定了采用删除策略,来解决双写问题,当我们修改了数据之后,然后把缓存中的数据进行删除,查询时发现缓存中没有数据,则会从mysql中加载最新的数据,从而避免数据库和缓存不一致的问题

之前的update方法:

/*** 更新商铺信息** @param shop 商铺数据* @return 无*/
@PutMapping
public Result updateShop(@RequestBody Shop shop) {// 写入数据库shopService.updateById(shop);return Result.ok();
}

修改后的update方法:

/*** 更新商铺信息** @param shop 商铺数据* @return 无*/
@PutMapping
public Result updateShop(@RequestBody Shop shop) {return shopService.update(shop);
}

新增一个方法,Impl里去实现

Result update(Shop shop);

实现类:

@Override
@Transactional
public Result update(Shop shop) {//首先先判一下空if (shop.getId() == null){return Result.fail("店铺id不能为空!!");}//先修改数据库updateById(shop);//再删除缓存stringRedisTemplate.delete(CACHE_SHOP_KEY + shop.getId());return Result.ok();
}

2.5 缓存穿透问题的解决思路

缓存穿透 :缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在,这样缓存永远不会生效,这些请求都会打到数据库。

1653326156516

常见的解决方案有两种:

  • 缓存空对象
    • 优点:实现简单,维护方便
    • 缺点:
      • 额外的内存消耗
      • 可能造成短期的不一致
  • 布隆过滤
    • 优点:内存占用较少,没有多余key
    • 缺点:
      • 实现复杂
      • 存在误判可能

**缓存空对象思路分析:**当我们客户端访问不存在的数据时,先请求redis,但是此时redis中没有数据,此时会访问到数据库,但是数据库中也没有数据,这个数据穿透了缓存,直击数据库,我们都知道数据库能够承载的并发不如redis这么高,如果大量的请求同时过来访问这种不存在的数据,这些请求就都会访问到数据库,简单的解决方案就是哪怕这个数据在数据库中也不存在,我们也把这个数据存入到redis中去,这样,下次用户过来访问这个不存在的数据,那么在redis中也能找到这个数据就不会进入到缓存了

**布隆过滤:**布隆过滤器其实采用的是哈希思想来解决这个问题,通过一个庞大的二进制数组,走哈希思想去判断当前这个要查询的这个数据是否存在,如果布隆过滤器判断存在,则放行,这个请求会去访问redis,哪怕此时redis中的数据过期了,但是数据库中一定存在这个数据,在数据库中查询出来这个数据后,再将其放入到redis中,

假设布隆过滤器判断这个数据不存在,则直接返回

这种方式优点在于节约内存空间,存在误判,误判原因在于:布隆过滤器走的是哈希思想,只要哈希思想,就可能存在哈希冲突

2.6 编码解决商品查询的缓存穿透问题:

核心思路如下:

在原来的逻辑中,我们如果发现这个数据在mysql中不存在,直接就返回404了,这样是会存在缓存穿透问题的

现在的逻辑中:如果这个数据不存在,我们不会返回404 ,还是会把这个数据写入到Redis中,并且将value设置为空,欧当再次发起查询时,我们如果发现命中之后,判断这个value是否是null,如果是null,则是之前写入的数据,证明是缓存穿透数据,如果不是,则直接返回数据。

1653327124561

  • 核心思路如下
  • 在原来的逻辑中,我们如果发现这个数据在MySQL中不存在,就直接返回一个错误信息了,但是这样存在缓存穿透问题
@Override
public Result queryById(Long id) {//先从Redis中查,这里的常量值是固定的前缀 + 店铺idString 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,设置TTLstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr,CACHE_SHOP_TTL, TimeUnit.MINUTES);//最终把查询到的商户信息返回给前端return Result.ok(shop);
}
  • 现在的逻辑是:如果这个数据不存在,将这个数据写入到Redis中,并且将value设置为空字符串,然后设置一个较短的TTL,返回错误信息。当再次发起查询时,先去Redis中判断value是否为空字符串,如果是空字符串,则说明是刚刚我们存的不存在的数据,直接返回错误信息
@Override
public Result queryById(Long id) {//先从Redis中查,这里的常量值是固定的前缀 + 店铺idString shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);//如果不为空(查询到了),则转为Shop类型直接返回if (StrUtil.isNotBlank(shopJson)) {Shop shop = JSONUtil.toBean(shopJson, Shop.class);return Result.ok(shop);}//如果查询到的是空字符串,则说明是我们缓存的空数据if (shopjson != null) {return Result.fail("店铺不存在!!");}//否则去数据库中查Shop shop = getById(id);//查不到,则将空字符串写入Redisif (shop == null) {//这里的常量值是2分钟stringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, "", CACHE_NULL_TTL, TimeUnit.MINUTES);return Result.fail("店铺不存在!!");}//查到了则转为json字符串String jsonStr = JSONUtil.toJsonStr(shop);//并存入redis,设置TTLstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr, CACHE_SHOP_TTL, TimeUnit.MINUTES);//最终把查询到的商户信息返回给前端return Result.ok(shop);
}

小总结:

缓存穿透产生的原因是什么?

  • 用户请求的数据在缓存中和数据库中都不存在,不断发起这样的请求,给数据库带来巨大压力

缓存穿透的解决方案有哪些?

  • 缓存null值
  • 布隆过滤
  • 增强id的复杂度,避免被猜测id规律(可以采用雪花算法
  • 做好数据的基础格式校验
  • 加强用户权限校验
  • 做好热点参数的限流

2.7 缓存雪崩问题及解决思路

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

1653327884526

解决方案:

  • 给不同的Key的TTL添加随机值,让其在不同时间段分批失效
  • 利用Redis集群提高服务的可用性(使用一个或者多个哨兵(Sentinel)实例组成的系统,对redis节点进行监控,在主节点出现故障的情况下,能将从节点中的一个升级为主节点,进行故障转义,保证系统的可用性。 )
  • 给缓存业务添加降级限流策略
  • 给业务添加多级缓存(浏览器访问静态资源时,优先读取浏览器本地缓存;访问非静态资源(ajax查询数据)时,访问服务端;请求到达Nginx后,优先读取Nginx本地缓存;如果Nginx本地缓存未命中,则去直接查询Redis(不经过Tomcat);如果Redis查询未命中,则查询Tomcat;请求进入Tomcat后,优先查询JVM进程缓存;如果JVM进程缓存未命中,则查询数据库)

2.8 缓存击穿问题及解决思路

缓存击穿问题也叫热点Key问题,就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了,无数的请求访问会在瞬间给数据库带来巨大的冲击。

1653328022622

常见的解决方案有两种:

  • 互斥锁
  • 逻辑过期

逻辑分析:假设线程1在查询缓存之后,本来应该去查询数据库,然后把这个数据重新加载到缓存的,此时只要线程1走完这个逻辑,其他线程就都能从缓存中加载这些数据了,但是假设在线程1没有走完的时候,后续的线程2,线程3,线程4同时过来访问当前这个方法, 那么这些线程都不能从缓存中查询到数据,那么他们就会同一时刻来访问查询缓存,都没查到,接着同一时间去访问数据库,同时的去执行数据库代码,对数据库访问压力过大

  • 解决方案一、使用锁来解决:

    • 因为锁能实现互斥性。假设线程过来,只能一个人一个人的来访问数据库,从而避免对于数据库访问压力过大,但这也会影响查询的性能,因为此时会让查询的性能从并行变成了串行,我们可以采用tryLock方法 + double check来解决这样的问题。

    • 假设现在线程1过来访问,他查询缓存没有命中,但是此时他获得到了锁的资源,那么线程1就会一个人去执行逻辑,假设现在线程2过来,线程2在执行过程中,并没有获得到锁,那么线程2就可以进行到休眠,休眠一会在重试,直到线程1把锁释放后,线程2获得到锁,然后再来执行逻辑,此时就能够从缓存中拿到数据了。

1653328288627

  • 解决方案二、逻辑过期方案

    • 方案分析:我们之所以会出现这个缓存击穿问题,主要原因是在于我们对key设置了过期时间,假设我们不设置过期时间,其实就不会有缓存击穿的问题,但是不设置过期时间,这样数据不就一直占用我们内存了吗,我们可以采用逻辑过期方案。

    • 我们把过期时间设置在 redis的value中,注意:这个过期时间并不会直接作用于redis,而是我们后续通过逻辑去处理。假设线程1去查询缓存,然后从value中判断出来当前的数据已经过期了,此时线程1去获得互斥锁,那么其他线程会进行阻塞,获得了锁的线程他会开启一个 线程去进行 以前的重构数据的逻辑,直到新开的线程完成这个逻辑后,才释放锁, 而线程1直接进行返回,假设现在线程3过来访问,由于线程线程2持有着锁,所以线程3无法获得锁,线程3也直接返回数据(但只能返回旧数据,牺牲了数据一致性,换取性能上的提高),只有等到新开的线程2把重建数据构建完后,其他线程才能走返回正确的数据。

    • 这种方案巧妙在于,异步的构建缓存,缺点在于在构建完缓存之前,返回的都是脏数据。

1653328663897

进行对比

**互斥锁方案:**由于保证了互斥性,所以数据一致,且实现简单,因为仅仅只需要加一把锁而已,也没其他的事情需要操心,所以没有额外的内存消耗,缺点在于有锁就有死锁问题的发生,且只能串行执行性能肯定受到影响

逻辑过期方案: 线程读取过程中不需要等待,性能好,有一个额外的线程持有锁去进行重构数据,但是在重构数据完成前,其他的线程只能返回之前的数据,且实现起来麻烦

1653357522914

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

  • 核心思路:相较于原来从缓存中查询不到数据后 直接查询数据库而言,现在的方案是 进行查询之后,如果从缓存没有查询到数据,则进行互斥锁的获取,获取互斥锁后,判断是否获得到了锁,如果没有获得到,则休眠,过一会再进行尝试,直到获取到锁为止,才能进行查询

  • 如果获取到了锁的线程,再去进行查询,查询后将数据写入redis,再释放锁,返回数据,利用互斥锁就能保证只有一个线程去执行操作数据库的逻辑,防止缓存击穿

1653357860001

image-20240821143510284

操作锁的代码:

  • 核心思路就是利用redis的setnx方法来表示获取锁,该方法含义是redis中如果没有这个key,则插入成功,返回1,在stringRedisTemplate中返回true, 如果有这个key则插入失败,则返回0,在stringRedisTemplate返回false,我们可以通过true,或者是false,来表示是否有线程成功插入key,成功插入的key的线程我们认为他就是获得到锁的线程。

  • 尝试获取锁:

    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);
    }
    
  • 释放锁:

    private void unlock(String key) {stringRedisTemplate.delete(key);
    }
    
  • 修改后的代码

    @Override
    public Shop queryWithMutex(Long id) {//1.先从Redis中查,这里的常量值是固定的前缀 + 店铺idString shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);//2.如果不为空(查询到了),则转为Shop类型直接返回if (StrUtil.isNotBlank(shopJson)) {//3. 存在,返回Shop shop = JSONUtil.toBean(shopJson, Shop.class);return shop;}//判断命中的是否是空值,这个是缓存穿透的逻辑if (shopJson != null) {return null;}//4.实现缓存重建Shop shop = null;try {//4.1获取锁boolean flag = tryLock(LOCK_SHOP_KEY + id);//4.2如果有锁,休眠后再查if (!flag) {Thread.sleep(50);return queryWithMutex(id);}//4.3 如果没有锁,再查一下缓存,double check一下shopJson = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);//4.4如果不为空(查询到了),则转为Shop类型直接返回if (StrUtil.isNotBlank(shopJson)) {//4.5 存在,返回shop = JSONUtil.toBean(shopJson, Shop.class);return shop;}//4.6 如果缓存还没有,则查数据库shop = getById(id);if (shop == null) {//将空值写入redisstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, "", CACHE_NULL_TTL, TimeUnit.MINUTES);return null;}//4.7 存在则写入redisString jsonStr = JSONUtil.toJsonStr(shop);//并存入redis,设置TTLstringRedisTemplate.opsForValue().set(CACHE_SHOP_KEY + id, jsonStr, CACHE_SHOP_TTL, TimeUnit.MINUTES);//最终把查询到的商户信息返回给前端} catch (InterruptedException e) {throw new RuntimeException(e);} finally {//释放锁unlock(LOCK_SHOP_KEY + id);}return shop;
    }
    
  • 最终修改queryById方法

    @Override
    public Result queryById(Long id) {Shop shop = queryWithMutex(id);if (shop == null) {return Result.fail("店铺不存在!!");}return Result.ok(shop);
    }
    

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

需求:修改根据id查询商铺的业务,基于逻辑过期方式来解决缓存击穿问题

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

1653360308731

double check一下是因为防止在检查过程中,别的现成已经更新缓存了,从造成再次更新缓存

image-20240821154639611

如果封装数据:因为现在redis中存储的数据的value需要带上过期时间,此时要么你去修改原来的实体类,要么你

步骤一、

新建一个实体类,我们采用第二个方案,这个方案,对原来代码没有侵入性。

@Data
public class RedisData {private LocalDateTime expireTime;private Object data;
}

步骤二、

ShopServiceImpl 新增此方法,利用单元测试进行缓存预热

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 {@Autowiredprivate ShopServiceImpl shopService;@Testpublic void test(){shopService.saveShop2Redis(1L,1000L);}
}

步骤三:正式代码

ShopServiceImpl

//这里需要声明一个线程池,因为下面我们需要新建一个现成来完成重构缓存
private static final ExecutorService CACHE_REBUILD_EXECUTOR = Executors.newFixedThreadPool(10);@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(time)) {//5. 未过期,直接返回商铺信息return shop;}//6. 过期,尝试获取互斥锁boolean flag = tryLock(LOCK_SHOP_KEY + id);//7. 获取到了锁if (flag) {//再次检查缓存中数据是否过期,如果没过期,则无需重建缓存json = stringRedisTemplate.opsForValue().get(CACHE_SHOP_KEY + id);//如果未命中,则返回空if (StrUtil.isBlank(json)) {return null;}//命中,将json反序列化为对象RedisData redisData = JSONUtil.toBean(json, RedisData.class);//将data转为Shop对象JSONObject shopJson = (JSONObject) redisData.getData();Shop shop = JSONUtil.toBean(shopJson, Shop.class);//获取过期时间LocalDateTime expireTime = redisData.getExpireTime();//判断是否过期if (LocalDateTime.now().isBefore(time)) {//未过期,直接返回商铺信息return shop;}//如果还是过期//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;
}

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

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

相关文章

初阶数据结构之计数排序

非比较排序 计数排序 计数排序⼜称为鸽巢原理&#xff0c;是对哈希直接定址法的变形应⽤。 操作步骤&#xff1a; 1&#xff09;统计相同元素出现次数 2&#xff09;根据统计的结果将序列回收到原来的序列中 #include "CountSort.h" void Count(int* arr, int n)…

线段树-点修区查

翻博客的时候突然发现线段树好像一个没有&#xff0c;我就准备把线段树给讲一下 分三个章节 点修区查 区修区查 区修区查&#xff08;带乘法&#xff09; 今天这一章比较简单&#xff0c;最多就区查稍微要动一点脑子 题目简介 输入n和m&#xff0c;n代表数的个数&#x…

读软件开发安全之道:概念、设计与实施05模式(上)

1. 模式 1.1. 模式分类 1.1.1. 设计属性 1.1.2. 暴露最少信息 1.1.3. 冗余 1.1.4. 强力执行 1.1.5. 信任与责任 1.1.6. 反模式 1.2. 模式可以缓解或者避免很多种类的风险&#xff0c;它们可以形成一个重要的工具箱&#xff0c;帮我们解决潜在的安全威胁 1.3. 不需要为…

学习设置echarts 折线图使用相关参数的方法整理

学习设置echarts 折线图使用相关参数的方法整理 折线图堆叠设置为不堆叠的方法 折线图堆叠设置为不堆叠的方法 官网是这样的&#xff0c;但是不需要这种堆叠形式的如下图&#xff1a; 第2条数据值 第1条数据值 第2条数据值 第3条数据值 第2条数据值 第3条数据值 需要改成…

C语言高手参考手册:函数进阶技巧

[大师C语言]合集&#xff3b;大师C语言(第一篇)&#xff3d;C语言栈溢出背后的秘密&#xff3b;大师C语言(第二十五篇)&#xff3d;C语言字符串探秘&#xff3b;大师C语言(第二篇)&#xff3d;C语言main函数背后的秘密&#xff3b;大师C语言(第二十六篇)&#xff3d;C语言结构体…

汽车管理 API 接口:开启高效车辆运营新时代

API&#xff08;Application Programming Interface&#xff09;是一种接口&#xff0c;用于不同软件之间的通信。在汽车管理领域&#xff0c;API的应用可以帮助提升车辆运营的效率&#xff0c;让车主和车辆管理者更方便地获取车辆相关信息&#xff0c;进行保养和维修等工作。本…

Linux yum提示Error downloading packages

很明显的错误&#xff0c;没有考虑过磁盘空间&#xff0c;记录一下。 Error downloading packages:gcc-4.8.5-44.el7.x86_64: Insufficient space in download directory /var/cache/yum/x86_64/7/base/packages* free 0 * needed 16 M使用du查看当前目录下所有文件大小 du …

黑马头条vue2.0项目实战(十一)——功能优化(组件缓存、响应拦截器、路由跳转与权限管理)

1. 组件缓存 1.1 介绍 先来看一个问题&#xff1f; 从首页切换到我的&#xff0c;再从我的回到首页&#xff0c;我们发现首页重新渲染原来的状态没有了。 首先&#xff0c;这是正常的状态&#xff0c;并非问题&#xff0c;路由在切换的时候会销毁切出去的页面组件&#xff…

HBase原理和操作

目录 一、HBase在Zookeeper中的存储元数据信息集群状态信息 二、HBase的操作Web Console命令行操作 三、HBase中数据的保存过程 一、HBase在Zookeeper中的存储 元数据信息 HBase的元数据信息是HBase集群运行所必需的关键数据&#xff0c;它存储在Zookeeper的"/hbase&quo…

数据结构——链式队列和循环队列

目录 引言 队列的定义 队列的分类 1.单链表实现 2.数组实现 队列的功能 队列的声明 1.链式队列 2.循环队列 队列的功能实现 1.队列初始化 (1)链式队列 (2)循环队列 (3)复杂度分析 2.判断队列是否为空 (1)链式队列 (2)循环队列 (3)复杂度分析 3.判断队列是否…

【具体数学 Concrete Mathematics】1.1.2 平面上的直线

【具体数学 Concrete Mathematics】1.1.2 平面上的直线

Django 第一课 -- 简介

目录 一. 基本介绍 二. 特点 三. MVC 与 MTV 模型 3.1. MVC 模型 3.2. MTV 模型 一. 基本介绍 Django 是一个由 Python 编写的一个开放源代码的 Web 应用框架。 Django 是一个高级的 Python Web 框架&#xff0c;用于快速开发可维护和可扩展的 Web 应用程序。 使用 Dja…

计算机毕业设计Python深度学习房价预测 房价可视化 链家爬虫 房源爬虫 房源可视化 卷积神经网络 大数据毕业设计 机器学习 人工智能 AI

基于python一/二手房数据爬虫分析预测系统可视化 商品房数据Flask框架&#xff08;附源码&#xff09; 项目介绍 技术栈&#xff1a; python语言、Flask框架、MySQL数据库、Echarts可视化 sklearn机器学习 多元线性回归预测模型、requests爬虫框架 链家一手房 一手房数据商品房…

docker连接宿主机redis,提示Connection refused

目录 一、测试环境 二、问题现象 三、问题总结 一、测试环境 centos 7 redis-5.0.14 docker-26.0.1 二、问题现象 服务器重启后docker连接宿主机redis&#xff0c;提示Connection refused Reconnecting, last destination was /172.25.xxx.x:6379 …

VMware vSphere Client无法访问和连接ESXi虚拟主机解决思路

文章目录 前言1. 问题现象2. 问题原因3. 解决方法4. 参考文章 前言 注意 : 可以先看看参考文章那里&#xff0c;在回过来看 1 、 2 、3 1. 问题现象 版本&#xff1a;VMware vCenter Server 5.5.0 build-2442329 问题描述&#xff1a;用VMware vSphere Client 登录ESXI主机出…

状态压缩、记忆化搜索---蒙德里安的梦想

291. 蒙德里安的梦想 - AcWing题库 求把 NMNM 的棋盘分割成若干个 1212 的长方形&#xff0c;有多少种方案。 例如当 N2&#xff0c;M4N2&#xff0c;M4 时&#xff0c;共有 55 种方案。当 N2&#xff0c;M3N2&#xff0c;M3 时&#xff0c;共有 33 种方案。 如下图所示&…

[数据集][目标检测]瞳孔虹膜检测数据集VOC+YOLO格式8768张2类别

数据集格式&#xff1a;Pascal VOC格式YOLO格式(不包含分割路径的txt文件&#xff0c;仅仅包含jpg图片以及对应的VOC格式xml文件和yolo格式txt文件) 图片数量(jpg文件个数)&#xff1a;8768 标注数量(xml文件个数)&#xff1a;8768 标注数量(txt文件个数)&#xff1a;8768 标注…

【微信小程序】自定义组件 - 数据、方法和属性

1. data 数据 2. methods 方法 在小程序组件中&#xff0c;事件处理函数和自定义方法需要定义到 methods 节点中&#xff0c;示例代码如下&#xff1a; 3. properties 属性 在小程序组件中&#xff0c;properties 是组件的对外属性&#xff0c;用来接收外界传递到组件中的数…

[Algorithm][贪心][跳跃游戏][加油站][单调递增的数字][坏了的计算器]详细讲解

目录 1.跳跃游戏1.题目链接2.算法思路详解3.代码实现 2.加油站1.题目链接2.算法原理详解3.代码实现 3.单调递增的数字1.题目链接2.算法原理详解3.代码实现 4.坏了的计算器1.代码实现2.算法原理详解3.代码实现 1.跳跃游戏 1.题目链接 跳跃游戏 2.算法思路详解 贪心&#xff1…

记忆化搜索与状态压缩:优化递归与动态规划的利器

记忆化搜索是解决递归和动态规划问题的一种高效优化技术。它结合了递归的灵活性和动态规划的缓存思想&#xff0c;通过保存已经计算过的子问题结果&#xff0c;避免了重复计算&#xff0c;大幅提升了算法的效率。当问题状态复杂时&#xff0c;状态压缩技术可以进一步优化空间使…