标准网站建设服务器,搭建创新平台,免费ppt模板公众号,石家庄网站建设系统#x1f697;Redis应用学习第二站~ #x1f6a9;起始站#xff1a;【Redis应用】基于Redis实现共享session登录(一) #x1f6a9;本文已收录至专栏#xff1a;Redis技术学习 #x1f44d;希望您能有所收获#xff0c;底部附有完整思维导图 一.概述
本篇我们会一起来学习… Redis应用学习·第二站~ 起始站【Redis应用】基于Redis实现共享session登录(一) 本文已收录至专栏Redis技术学习 希望您能有所收获底部附有完整思维导图 一.概述
本篇我们会一起来学习什么是缓存为什么需要缓存然后通过一个实际的案例一起了解并解决使用缓存过程中碰到的数据库缓存不一致问题、缓存穿透问题、缓存雪崩问题、缓存击穿问题。
(1) 什么是缓存?
举个例子:越野车,山地自行车,都拥有避震器,防止车体加速后因惯性,在酷似U字母的地形上飞跃,硬着陆导致的损害,像个弹簧一样;
同样,实际开发中,系统也需要避震器,防止过高的数据访问猛冲系统,导致其操作线程无法及时处理信息而瘫痪;
这在实际开发中对企业讲,对产品口碑,用户评价都是致命的(b站崩了qq崩了微博崩了…);
缓存(Cache),就是指数据交换的缓冲区,俗称的缓存就是缓冲区内的数据,一般从数据库中获取数据,临时存储于本地代码相对于IO操作读写性能较高。例如:
例1:Static final ConcurrentHashMapK,V map new ConcurrentHashMap(); 本地用于高并发例2:static final CacheK,V USER_CACHE CacheBuilder.newBuilder().build(); 可用于结合redis等缓存例3:Static final MapK,V map new HashMap(); 本地缓存由于其被Static修饰,所以随着类的加载而被加载到内存之中,作为本地缓存,由于其又被final修饰,所以其引用(例3:map)和对象(例3:new HashMap())之间的关系是固定的,**不能改变,**因此不用担心赋值()导致缓存失效;
(2) 为什么要使用缓存
由于缓存数据存储于代码中,而代码运行在内存中,内存的读写性能远高于磁盘,由此可以大大降低用户访问并发量带来的服务器读写压力
实际开发过程中,企业的数据量,少则几十万,多则几千万,这么大数据量,如果没有缓存来作为避震器,系统是几乎撑不住的,所以企业会大量运用到缓存技术;
但是缓存也会增加代码复杂度和运营的成本
优点 降低后端负载复杂SQL查询给数据库带来巨大压力如果在缓存中查到数据可以直接返回不用查询数据库 提高读写效率降低响应时间基于内存速度非常快
成本 数据一致性成本如果数据库中数据发生了改变但缓存中数据未及时更新导致两处数据不一致 代码维护成本需解决一致性问题及其中碰到的各种问题例如数据修改时缓存中数据更新 运维成本人力维护多台设备
(3) 如何使用缓存
实际开发中,会构筑多级缓存来使系统运行速度进一步提升,例如:本地缓存与redis中的缓存并发使用
浏览器缓存主要是存在于浏览器端的缓存
应用层缓存可以分为tomcat本地缓存比如之前提到的map或者是使用redis作为缓存
数据库缓存在数据库中有一片空间是 buffer pool增改查数据都会先加载到mysql的缓存中
CPU缓存当代计算机最大的问题是 cpu性能提升了但内存读写速度没有跟上所以为了适应当下的情况增加了cpu的L1L2L3级的缓存
二.添加商户查询缓存
(1) 引子
接下来让我们结合实际案例一起学习缓存技术的使用以及如何解决在这其中碰到的常见问题。
在我们查询商户信息时通常我们是直接从数据库中去进行查询的而直接查询数据库相对来说那肯定慢咯例如:
GetMapping(/{id})
public Result queryShopById(PathVariable(id) Long id) {//这里是直接查询数据库return shopService.queryById(id);
}为了更好的用户体验我们可以考虑增加缓存以提高页面响应速度。
(2) 缓存模型和思路
(2.1) 业务流程
标准的操作方式就是查询数据库之前先查询缓存如果缓存数据存在则直接从缓存中返回如果缓存数据不存在再查询数据库然后将数据存入redis再返回数据。
(2.2) 代码实现
上述代码可以进行如下改造
代码思路如果缓存有则直接返回如果缓存不存在则查询数据库然后存入redis再返回。
启动项目F12打开开发者模式查看network,刷新两次我们可以发现首次查询由于没有缓存直接从数据库中获取数据花费了1.7s,再次查询由于缓存中有数据查询的是缓存直接返回数据只花了几十毫秒响应速度显著提升。
当然引入缓存给我们带来好处的同时也给我们带来了许多的问题例如我们同时的把数据保存在数据库和缓存中当我们对数据库中数据进行更改时缓存中数据并不会更新当用户查询时查到的就是原来的旧数据与数据库不一致这可能导致诸多问题。接下来让我们一起看看如何解决此问题~
三.缓存更新策略
(1) 三种常见策略
由于内存是有限的缓存更新是redis为了节约内存而设计出来的一个东西当我们向redis插入太多数据此时就可能会导致缓存中的数据过多所以redis会对部分数据进行更新或者把他叫为淘汰更合适。
内存淘汰redis自动进行当redis内存达到咱们设定的max-memery的时候会自动触发淘汰机制淘汰掉一些不重要的数据(可以自己设置策略方式)
超时剔除当我们给redis设置了过期时间ttl之后redis会将超时的数据进行删除方便继续使用缓存
主动更新我们可以手动调用方法把缓存删掉通常用于解决缓存和数据库不一致问题
(2) 主动更新解决方案思考
由于我们的缓存的数据源来自于数据库,而数据库的数据是会发生变化的,因此,如果当数据库中数据发生变化,而缓存却没有同步,用户通过缓存拿到的数据就可能是旧数据此时就会有一致性问题存在,我们可以选择主动更新来手动解决数据库缓存不一致问题而主动更新又有三种常见的方案 Cache Aside Pattern 人工编码方式缓存调用者在更新完数据库后再去更新缓存也称之为双写方案。 稍微复杂需要自己编码进行控制 Read/Write Through Pattern : 由系统本身完成数据库与缓存的问题交由系统本身去处理。 维护服务比较困难开发起来成本较高 Write Behind Caching Pattern 调用者只操作缓存其他线程去异步处理数据库实现最终一致。 需要实时监控缓存数据的变更此外如果缓存服务出现了宕机会导致数据丢失 (3) 数据库缓存不一致解决
综合考虑我们使用方案一由于其需要开发者自己进行编码因此操作缓存和数据库时有三个问题需要考虑
删除缓存还是更新缓存 更新缓存每次更新数据库都更新缓存无效写操作较多 √删除缓存更新数据库时让缓存失效查询时再更新缓存 ×
假设我们每次操作数据库后都操作缓存但是中间如果没有人查询那么这个更新动作实际上只有最后一次生效中间的更新动作意义并不大我们可以把缓存删除等待再次查询时将缓存中的数据加载出来。 如何保证缓存与数据库的操作的同时成功或失败 单体系统将缓存与数据库操作放在一个事务分布式系统利用TCC等分布式事务方案 先操作缓存还是先操作数据库 先删除缓存再操作数据库 ×先操作数据库再删除缓存 √
我们应当是先操作数据库再删除缓存由于查询数据库比写入数据库快由此可能产生一系列问题。
当两个线程并发来访问时假设线程1先来他先把缓存删了由于其执行的是更新操作相对较慢此时线程2过来执行查询操作他发现缓存数据并不存在于是查询数据库并重新写入缓存而此时线程1并未完成更新操作数据库中还是旧数据由此写入缓存的也是旧数据等线程1完成更新动作时也就导致了数据库中数据与缓存数据不一致。
当然先操作数据库再删除缓存也存在一些问题例如同样当两个线程并发来访问时假设缓存由于某种原因失效了线程1查询缓存发现没有数据于是去查询数据库正当其准备写入缓存之际线程2突然执行更新数据库操作然后将缓存删除这时线程1才写入缓存而写入的是未更新数据库之前的旧数据此时同样造成了数据库中数据与缓存数据不一致。
似乎两种方案都存在问题那么我们该如何抉择呢
由于写入缓存的速度非常快在此期间恰好完成更新与删除操作的概率比较小。由此我们可以先操作数据库再删除缓存。
(4) 代码实现双写一致
同样是上述根据id查询店铺代码我们可以进行一些改造 根据id查询店铺时如果缓存未命中则查询数据库将数据库结果写入缓存并设置超时时间兜底 根据id修改店铺时先修改数据库再删除缓存
首先修改查询代码与上述基本一致补充设置redis缓存过期时间
其次修改更新店铺信息代码逻辑我们应该先对数据库中的数据进行修改然后把缓存中的数据进行删除查询时发现缓存中没有数据则会从mysql中加载最新的数据从而避免数据库和缓存不一致的问题。
至此我们便极大的减少了数据不一致问题发送的概率。
四.缓存穿透问题
(1) 概述
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在这样缓存永远不会生效这些请求都会打到数据库。
通俗来说就是当我们客户端访问不存在的数据时先请求redis但是此时redis中没有数据此时会访问到数据库但是数据库中也没有数据这个数据穿透了缓存直击数据库我们都知道数据库能够承载的并发不如redis这么高如果大量的请求同时过来访问这种不存在的数据这些请求就都会访问到数据库。假设一个不怀好意的人开启无数个线程并发请求这些请求将避开缓存都落到数据库上由此就可能导致数据库因扛不住压力而故障。
常见的解决方案有两种
缓存空对象 优点实现简单维护方便缺点 额外的内存消耗可能造成短期的不一致
思路分析当接收到请求时如果数据在缓存和数据库中都不存在为了避免一些恶意攻击者的重复请求我们可以将一个空值缓存到redis中并设置过期时间这样下次用户过来访问这个不存在的数据那么在redis中也能找到这个数据请求就不会进入到数据库中了而且可以自动清理无效数据
布隆过滤 优点内存占用较少没有多余key缺点 实现复杂存在误判可能
思路分析布隆过滤器其实采用的是哈希思想来解决这个问题通过一个庞大的二进制数组走哈希思想去判断当前这个要查询的这个数据是否存在如果布隆过滤器判断存在则放行这个请求会去访问redis哪怕此时redis中的数据过期了但是数据库中一定存在这个数据在数据库中查询出来这个数据后再将其放入到redis中假设布隆过滤器判断这个数据不存在则直接返回
这种方式优点在于节约内存空间但存在误判误判原因在于布隆过滤器走的是哈希思想只要哈希思想就可能存在哈希冲突
此外我们还可以通过增强id的复杂度避免被猜测id规律、做好数据的基础格式校验、加强用户权限校验、做好热点参数的限流等策略来规避缓存穿透问题。
(2) 问题解决
接下来让我们一起通过缓存空对象来解决缓存穿透问题。
(2.1) 业务流程
在原来的逻辑中我们如果发现这个数据在mysql中不存在直接就返回404了这样是会存在缓存穿透问题的
现在的逻辑中如果这个数据不存在我们不会返回404 还是会把这个数据写入到Redis中并且将value设置为空当再次发起查询时我们如果发现命中之后判断这个value是否是null如果是null则是之前写入的数据证明是缓存穿透数据直接结束如果不是则直接返回数据。
(2.2) 代码实现
让我们来修改一下上述根据商户id查询商户的业务逻辑
Override
public Result queryById(Long id) {String key CACHE_SHOP_KEY id;//1. 从redis查询商铺缓存String shopJson stringRedisTemplate.opsForValue().get(key);//2. 判断是否存在if (StrUtil.isNotBlank(shopJson)) {//3. 存在,直接返回Shop shop JSONUtil.toBean(shopJson, Shop.class);return Result.ok(shop);}// 判断命中的是否是空值if (shopJson ! null) {// 返回错误信息return Result.fail(店铺不存在!);}//4. 不存在,根据id查询数据库Shop shop getById(id);// 5. 不存在,返回错误if (shop null) {// 将空值写入redisstringRedisTemplate.opsForValue().set(key, , 2L, TimeUnit.MINUTES);// 返回错误信息return Result.fail(店铺不存在!);}// 6. 存在,写入redisstringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(shop), 30L, TimeUnit.MINUTES);//7.返回return Result.ok(shop);
}重新启动测试可以发现重复查询一个不存在的数值将被我们设置的空值缓存拦截从而规避多次打到数据库。
五.缓存雪崩问题
缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机导致大量请求到达数据库带来巨大压力。
解决方案
给不同的Key的TTL添加随机值,避免同时过期利用Redis集群提高服务的可用性例如使用哨兵机制实现服务的监控给缓存业务添加降级限流策略给业务添加多级缓存
六.缓存击穿问题
(1) 概述
缓存击穿问题也叫热点Key问题就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了无数的请求访问会在瞬间给数据库带来巨大的冲击 。
问题分析假设某个高并发访问的缓存失效了线程1在查询缓存发现为空之后本来应该去查询数据库然后把这个数据重新加载到缓存的此时只要线程1走完这个逻辑其他线程就都能从缓存中加载这些数据了但是假设在线程1没有走完的时候后续的线程2线程3线程4同时过来访问当前这个方法那么他们就会同一时刻来访问查询缓存结果都没查到接着同一时间去访问数据库同时的去执行数据库代码对数据库访问压力过大 常见的解决方案有两种
互斥锁逻辑过期
方案对比 互斥锁方案由于保证了互斥性所以数据一致且实现简单因为仅仅只需要加一把锁而已也没其他的事情需要操心所以没有额外的内存消耗缺点在于有锁就有死锁问题的发生且只能串行执行性能肯定受到影响 逻辑过期方案 线程读取过程中不需要等待性能好有一个额外的线程持有锁去进行重构数据但是在重构数据完成前其他的线程只能返回之前的数据且实现起来麻烦 (2) 互斥锁解决方案
(2.1) 思路分析
因为锁能实现互斥性。假设线程过来我们可以限制只能一个人一个人的来访问数据库从而避免对于数据库访问压力过大但这也会影响查询的性能因为此时会让查询的性能从并行变成了串行我们可以采用tryLock方法 double check来解决这样的问题。
假设现在线程1过来访问他查询缓存没有命中但是此时他获得到了锁的资源那么线程1就会一个人去执行逻辑假设现在线程2过来线程2在执行过程中并没有获得到锁那么线程2就可以进行到休眠直到线程1把锁释放后线程2获得到锁然后再来执行逻辑此时就能够从缓存中拿到数据了。
(2.2) 业务流程
相较于原来从缓存中查询不到数据后直接查询数据库而言现在的方案是:
进行查询之后如果从缓存没有查询到数据则进行互斥锁的获取获取互斥锁后判断是否获得到了锁如果没有获得到则休眠过一会再进行尝试直到获取到锁为止才能进行查询如果获取到了锁的线程再次检查redis缓存是否存在做DoubleCheck.如果存在则无需重建缓存直接返回否则进行查询然后将数据写入redis再释放锁返回数据。
利用互斥锁就能保证只有一个线程去执行操作数据库的逻辑防止缓存击穿
我们可以利用redis的setnx方法来表示获取锁该方法的作用是redis中如果没有这个key则插入成功返回1在stringRedisTemplate中返回true 如果有这个key则插入失败则返回0在stringRedisTemplate返回false我们可以通过true或者是false来表示是否有线程成功插入key成功插入的key的线程我们认为他就是获得到锁的线程。
(2.3) 代码实现
我们首先声明两个方法用于获取锁和释放锁
// 获取锁
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);
}为了方便我们可以封装一个使用互斥锁解决缓存穿透方法
public Shop queryWithMutex(Long id) {String key CACHE_SHOP_KEY id;// 1、从redis中查询商铺缓存String shopJson stringRedisTemplate.opsForValue().get(key);// 2、判断是否存在if (StrUtil.isNotBlank(shopJson)) {// 存在,直接返回return JSONUtil.toBean(shopJson, Shop.class);}//判断命中的值是否是空值缓存穿透解决if (shopJson ! null) {//返回一个错误信息return null;}// 4.实现缓存重构//4.1 获取互斥锁String lockKey lock:shop: id;Shop shop null;try {boolean isLock tryLock(lockKey);// 4.2 判断否获取成功if(!isLock){//4.3 失败则休眠重试Thread.sleep(50);return queryWithMutex(id);}// 获取到锁再次判断doublecheck// 从缓存中查询数据,成功获取锁,判断其他线程是否重建缓存jsonShop stringRedisTemplate.opsForValue().get(key);// 如果其他线程已经重建缓存则直接返回if (StrUtil.isNotBlank(jsonShop)) {Shop cacheShop JSONUtil.toBean(jsonShop, Shop.class);return cacheShop;}//4.4 否则根据id查询数据库shop getById(id);// 5.不存在返回错误if(shop null){//将空值写入redis缓存穿透解决stringRedisTemplate.opsForValue().set(key,,CACHE_NULL_TTL,TimeUnit.MINUTES);//返回错误信息return null;}q//6.写入redisstringRedisTemplate.opsForValue().set(key,JSONUtil.toJsonStr(shop),CACHE_NULL_TTL,TimeUnit.MINUTES);}catch (Exception e){throw new RuntimeException(e);}finally {//7.释放互斥锁unlock(lockKey);}return shop;}调用互斥锁解决方案方法
Override
public Result queryShopById(Long id) {//1.互斥锁解决缓存穿透Shop shop queryWithMutex(id);if (shop null) {return Result.fail(店铺不存在);}return Result.ok(shop);
}启动使用jmeter进行测试我们可以发现我们已经成功规避了缓存击穿问题
(3) 逻辑过期解决方案
(3.1) 思路分析
我们之所以会出现这个缓存击穿问题主要原因是在于我们对key设置了过期时间假设我们不设置过期时间其实就不会有缓存击穿的问题但是不设置过期时间这样数据不就一直占用我们内存了吗由此我们可以采用逻辑过期方案。
我们把过期时间设置在 redis的value中注意这个过期时间并不会直接作用于redis而是我们后续通过逻辑去处理。假设线程1去查询缓存然后从value中判断出来当前的数据已经过期了此时线程1去获得互斥锁那么其他线程会进行阻塞获得了锁的线程会开启一个新的线程2去进行以前的重构数据的逻辑 而线程1直接返回过期数据新开的线程2完成这个逻辑后才释放锁假设现在线程3过来访问由于线程线程2持有着锁所以线程3无法获得锁线程3也直接返回过期数据只有等到新开的线程2把重建数据构建完后其他线程才能走返回正确的数据。
这种方案巧妙在于异步的构建缓存缺点在于在构建完缓存之前返回的都是脏数据。
(3.2) 业务流程
当用户开始查询redis时判断是否命中如果没有命中则直接返回空数据不查询数据库而一旦命中后将value取出判断value中的过期时间是否满足如果没有过期则直接返回redis中的数据如果过期则在开启独立线程后直接返回之前的数据独立线程去重构数据重构完成后释放互斥锁。
(3.3) 代码实现
因为现在redis中存储的数据的value需要带上过期时间此时要么你去修改原来的实体类添加一个过期时间字段要么你新建一个实体类我们采用第二个方案这个方案对原来代码没有侵入性。
Data
public class RedisData {private LocalDateTime expireTime;private Object data;
}在ShopServiceImpl 新增一个方法利用单元测试进行模拟缓存预热
在测试类中
逻辑过期业务逻辑处理此处我们仍然选择封装一个逻辑过期解决方案方法。
// 创建线程池
private static final ExecutorService CACHE_REBUILD_EXECUTOR Executors.newFixedThreadPool(10);public Shop queryWithLogicalExpire(Long id ) {String key CACHE_SHOP_KEY id;// 1.从redis查询商铺缓存String json stringRedisTemplate.opsForValue().get(key);// 2.判断是否存在if (StrUtil.isBlank(json)) {// 3.存在直接返回return null;}// 4.命中需要先把json反序列化为对象RedisData redisData JSONUtil.toBean(json, RedisData.class);Shop shop JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);LocalDateTime expireTime redisData.getExpireTime();// 5.判断是否过期if(expireTime.isAfter(LocalDateTime.now())) {// 5.1.未过期直接返回店铺信息return shop;}// 5.2.已过期需要缓存重建// 6.缓存重建// 6.1.获取互斥锁String lockKey LOCK_SHOP_KEY id;boolean isLock tryLock(lockKey);// 6.2.判断是否获取锁成功if (isLock){// 获取到锁再次判断doublecheck// 从缓存中查询数据,成功获取锁,判断其他线程是否重建缓存json stringRedisTemplate.opsForValue().get(key);if (StrUtil.isBlank(json)) {// 存在直接返回return null;}// 命中需要先把json反序列化为对象redisData JSONUtil.toBean(json, RedisData.class);shop JSONUtil.toBean((JSONObject) redisData.getData(), Shop.class);expireTime redisData.getExpireTime();// 判断是否过期if(expireTime.isAfter(LocalDateTime.now())) {// 未过期直接返回店铺信息return shop;}// 如果过期则开启新线程CACHE_REBUILD_EXECUTOR.submit( ()-{try{//重建缓存this.saveShop2Redis(id,20L);}catch (Exception e){throw new RuntimeException(e);}finally {unlock(lockKey);}});}// 6.4.返回过期的商铺信息return shop;
}在正式方法中调用逻辑过期解决方法方法 Overridepublic Result queryShopById(Long id) {//缓存击穿逻辑过期解决方案Shop shop queryWithLogicalExpire(id);if (shop null) {return Result.fail(店铺不存在);}return Result.ok(shop);}再次使用jmeter进行测试我们可以发现在一次并发查询中在缓存重建期间我们查询到的还是旧数据当重建完成后便是新数据了
七.封装Redis工具类
通常我们都会选择将上述解决方案封装为工具类使用如下我们基于StringRedisTemplate封装一个简单的缓存工具类满足下列需求 方法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);// 注入StringRedisTemplatepublic CacheClient(StringRedisTemplate stringRedisTemplate) {this.stringRedisTemplate stringRedisTemplate;}// 方法1将任意Java对象序列化为json并存储在string类型的key中并且可以设置TTL过期时间public void set(String key, Object value, Long time, TimeUnit unit) {stringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(value), time, unit);}// 方法2将任意Java对象序列化为json并存储在string类型的key中并且可以设置逻辑过期时间用于处理缓存击穿问题public void setWithLogicalExpire(String key, Object value, Long time, TimeUnit unit) {// 设置逻辑过期RedisData redisData new RedisData();redisData.setData(value);redisData.setExpireTime(LocalDateTime.now().plusSeconds(unit.toSeconds(time)));// 写入RedisstringRedisTemplate.opsForValue().set(key, JSONUtil.toJsonStr(redisData));}// 方法3根据指定的key查询缓存并反序列化为指定类型利用缓存空值的方式解决缓存穿透问题// 使用泛型替代具体类型使得方法更加通用public R,ID R queryWithPassThrough(String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit){String key keyPrefix id;// 1.从redis查询商铺缓存String json stringRedisTemplate.opsForValue().get(key);// 2.判断是否存在if (StrUtil.isNotBlank(json)) {// 3.存在直接返回return JSONUtil.toBean(json, type);}// 判断命中的是否是空值if (json ! null) {// 返回一个错误信息return null;}// 4.不存在根据id查询数据库R r dbFallback.apply(id);// 5.不存在返回错误if (r null) {// 将空值写入redisstringRedisTemplate.opsForValue().set(key, , CACHE_NULL_TTL, TimeUnit.MINUTES);// 返回错误信息return null;}// 6.存在写入redisthis.set(key, r, time, unit);return r;}// 方法4根据指定的key查询缓存并反序列化为指定类型需要利用逻辑过期解决缓存击穿问题public R, ID R queryWithLogicalExpire(String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) {String key keyPrefix id;// 1.从redis查询商铺缓存String json stringRedisTemplate.opsForValue().get(key);// 2.判断是否存在if (StrUtil.isBlank(json)) {// 3.存在直接返回return null;}// 4.命中需要先把json反序列化为对象RedisData redisData JSONUtil.toBean(json, RedisData.class);R r JSONUtil.toBean((JSONObject) redisData.getData(), type);LocalDateTime expireTime redisData.getExpireTime();// 5.判断是否过期if(expireTime.isAfter(LocalDateTime.now())) {// 5.1.未过期直接返回店铺信息return r;}// 5.2.已过期需要缓存重建// 6.缓存重建// 6.1.获取互斥锁String lockKey LOCK_SHOP_KEY id;boolean isLock tryLock(lockKey);// 6.2.判断是否获取锁成功if (isLock){// 进行doublecheck// 从redis查询商铺缓存json stringRedisTemplate.opsForValue().get(key);// 判断是否存在if (StrUtil.isBlank(json)) {// 存在直接返回return null;}// 命中需要先把json反序列化为对象redisData JSONUtil.toBean(json, RedisData.class);r JSONUtil.toBean((JSONObject) redisData.getData(), type);expireTime redisData.getExpireTime();// 5.判断是否过期if(expireTime.isAfter(LocalDateTime.now())) {// 5.1.未过期直接返回店铺信息return r;}// 6.3.成功开启独立线程实现缓存重建CACHE_REBUILD_EXECUTOR.submit(() - {try {// 查询数据库R newR dbFallback.apply(id);// 重建缓存this.setWithLogicalExpire(key, newR, time, unit);} catch (Exception e) {throw new RuntimeException(e);}finally {// 释放锁unlock(lockKey);}});}// 6.4.返回过期的商铺信息return r;}// 方法5根据指定的key查询缓存并反序列化为指定类型需要利用互斥锁解决缓存击穿问题public R, ID R queryWithMutex(String keyPrefix, ID id, ClassR type, FunctionID, R dbFallback, Long time, TimeUnit unit) {String key keyPrefix id;// 1.从redis查询商铺缓存String shopJson stringRedisTemplate.opsForValue().get(key);// 2.判断是否存在if (StrUtil.isNotBlank(shopJson)) {// 3.存在直接返回return JSONUtil.toBean(shopJson, type);}// 判断命中的是否是空值if (shopJson ! null) {// 返回一个错误信息return null;}// 4.实现缓存重建// 4.1.获取互斥锁String lockKey LOCK_SHOP_KEY id;R r null;try {boolean isLock tryLock(lockKey);// 4.2.判断是否获取成功if (!isLock) {// 4.3.获取锁失败休眠并重试Thread.sleep(50);return queryWithMutex(keyPrefix, id, type, dbFallback, time, unit);}// 获取到锁再次判断doublecheck// 从缓存中查询数据,成功获取锁,判断其他线程是否重建缓存String shopJson stringRedisTemplate.opsForValue().get(key);// 判断是否存在if (StrUtil.isNotBlank(shopJson)) {// 存在直接返回return JSONUtil.toBean(shopJson, type);}// 4.4.获取锁成功根据id查询数据库r dbFallback.apply(id);// 5.不存在返回错误if (r null) {// 将空值写入redisstringRedisTemplate.opsForValue().set(key, , CACHE_NULL_TTL, TimeUnit.MINUTES);// 返回错误信息return null;}// 6.存在写入redisthis.set(key, r, time, unit);} catch (InterruptedException e) {throw new RuntimeException(e);}finally {// 7.释放锁unlock(lockKey);}// 8.返回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);}
}在ShopServiceImpl 使用中工具类
Resource
private CacheClient cacheClient;Overridepublic Result queryById(Long id) {// 解决缓存穿透Shop shop cacheClient.queryWithPassThrough(CACHE_SHOP_KEY, id, Shop.class, this::getById, CACHE_SHOP_TTL, TimeUnit.MINUTES);// 互斥锁解决缓存击穿// Shop shop cacheClient// .queryWithMutex(CACHE_SHOP_KEY, id, Shop.class, this::getById, CACHE_SHOP_TTL, TimeUnit.MINUTES);// 逻辑过期解决缓存击穿// Shop shop cacheClient// .queryWithLogicalExpire(CACHE_SHOP_KEY, id, Shop.class, this::getById, 20L, TimeUnit.SECONDS);if (shop null) {return Result.fail(店铺不存在);}// 7.返回return Result.ok(shop);}八.思维导图
