写到第七天苍穹外卖这个项目的主干其实已经基本成型了后端能启动员工端能管理分类和菜品用户端能登录、能看店、能看菜单。但如果你真的自己点开过小程序页面或者拿压测工具跑过一遍会发现一个很现实的问题——用户每次打开菜单都要从MySQL里把菜品数据查一遍。数据量不大但架不住请求多到饭点高峰那一下数据库连接数能飙得让人心虚。day07这天的任务就是把用户端查询这条链路从“能跑”变成“扛得住”。核心手段是给高频查询接口加缓存用的技术栈是Spring Cache加Redis。这篇我就把这一天的改造过程、注解选择、缓存一致性处理和上线后的几个经典坑完整拆开讲一遍给正在跟这个项目的同学一个参考。1. day07到底在做什么用户端查询链路梳理1.1 为什么在这个节点引入缓存苍穹外卖做到第六天用户端的微信登录、店铺状态、分类查询、菜品浏览都已经打通。这时项目整体处于一个“功能齐全但性能裸奔”的状态。拿用户打开小程序点外卖这个动作举例背后的接口调用路径大概是这样的进入首页查店铺营业状态进入点餐页按分类加载菜品列表点击某个分类再查一次该分类下的菜品和套餐每次切换分类都会重新查询数据库。这些接口有一个共同特征读多写少。菜品数据在管理端被修改的频率很低但用户端的读取频率极高而且早晚高峰的请求集中度非常明显。如果没有缓存每次读取都要走一遍“建立连接、执行SQL、封装结果”的完整流程数据库压力大响应时间也容易波动。到这个节点引入缓存不是因为之前的代码有问题而是因为项目已经到了需要区分“写路径”和“读路径”的阶段。管理端负责维护数据用户端负责消费数据中间用一层缓存把两侧隔开这是业务系统最经典的架构演进路径。1.2 需要优先加缓存的接口范围day07盯住的是用户端的高频读接口具体来说就是用Cache模块下这几个接口接口数据特征不缓存时的问题根据分类id查询菜品列表查询频繁数据基本不变每次全量查库根据分类id查询套餐列表查询频繁数据基本不变每次全量查库根据id查询菜品详情点餐页高频访问单行查询也要建连这里有个容易被忽略的点套餐列表和菜品列表的查询参数看似只有categoryId但实际查询条件还包括status字段只查启售状态的商品。这个细节直接关系到后面缓存key的设计如果key里漏掉查询条件就会出现缓存了禁用菜品的问题这个我放到第三章详细说。1.3 缓存选型的现实依据很多同学会问为什么不直接手写RedisTemplate操作而是引入Spring Cache我在确认方案之前也对比过。手写Redis缓存的好处是控制力强可以对每个key精确管理过期时间但坏处是代码侵入性大一个查询方法里要塞进大量的序列化、反序列化和key拼接逻辑而且缓存清理逻辑散落在业务代码里很容易漏。Spring Cache则是把缓存操作抽象成注解业务方法只需要关心自己的逻辑缓存行为通过Cacheable这些注解声明式地附加到方法上侵入性小代码可读性高。对于苍穹外卖这种业务复杂度不高的项目Spring Cache是完全够用的而且后面维护起来省心。2. Spring Cache和Redis是怎么配合工作的2.1 Spring Cache解决的三个核心问题Spring Cache是Spring框架提供的一套缓存抽象它解决的核心问题有三个第一缓存操作的声明式注入。开发者在方法上标注注解框架在方法执行前检查缓存执行后写入缓存开发者不需要关心底层缓存API。第二缓存实现的可插拔。它定义了一套统一接口CacheManager底层可以用Redis、Ehcache、Caffeine甚至是一个ConcurrentHashMap来当缓存实现。切换缓存中间件时业务代码完全不用改。第三缓存异常不影响主流程。默认情况下缓存读写抛出的异常会被吞掉保证核心业务不因为缓存故障而中断。但要知道Spring Cache本身并不实现存储它只是给你提供“操作缓存”的门面。真正把数据存下来的是RedisCacheManager这个具体实现它负责告诉Spring Cache“拿Redis当存储介质key怎么序列化value怎么序列化过期时间多久”。2.2 Spring Cache常用的三个注解这一天的开发主要用到三个注解先把语义理清楚Cacheable方法执行前先查缓存命中就直接返回缓存结果不执行方法体未命中就执行方法体并把返回值放入缓存。CachePut方法执行后把返回值更新到缓存。不查缓存每次都执行方法。CacheEvict方法执行后删除指定的缓存。这中间最容易弄混的是Cacheable和CachePut。简单记前者是“读的时候用”后者是“写的时候顺手把缓存更新掉”。而CacheEvict的逻辑最简单粗暴——数据变了直接删缓存等下次查询时再重建。2.3 RedisCacheManager配置的几个关键点Spring Boot 2.x版本下需要在配置类里手动构建RedisCacheManager。直接看代码Configuration EnableCaching public class RedisCacheConfig { Bean public CacheManager cacheManager(RedisConnectionFactory connectionFactory) { RedisCacheConfiguration defaultConfig RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30)) .serializeKeysWith( RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()) ) .serializeValuesWith( RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()) ) .disableCachingNullValues(); return RedisCacheManager.builder(connectionFactory) .cacheDefaults(defaultConfig) .build(); } }这里有三个必须解释清楚的设计缺一个后面都会踩坑。第一个是key序列化器用StringRedisSerializervalue序列化器用GenericJackson2JsonRedisSerializer。如果不指定Spring Cache默认使用JDK序列化Redis里存的会是带类型头的二进制数据肉眼几乎没法排查。更重要的是JDK序列化要求缓存对象实现Serializable接口一旦实体类忘记实现运行期直接报错。改成JSON序列化Redis里的value是正常可读的JSON字符串排查问题方便很多。第二个是entryTtl默认设置了30分钟。过期时间在这里作为兜底机制存在就算后面缓存清理逻辑出错最坏情况下数据也会在30分钟后自动失效数据库会重新加载到最新数据。这个TTL设置是缓存系统最后一道安全网。第三个是disableCachingNullValues()。这个选项的作用是禁止缓存null值。背后有一个很微妙的考量如果查询数据库返回null框架会认为“缓存穿透的产物”而不是一个正常的缓存值。开启这个选项后空值不缓存防止大量非法请求把空结果也缓存下来把Redis打成“空数据仓库”。3. 菜品缓存改造的完整落地过程3.1 改造前的原始查询逻辑用户端查询菜品的代码最开始是service层直接查数据库然后把实体转换成VO返回给ControllerService public class DishServiceImpl implements DishService { Autowired private DishMapper dishMapper; public ListDishVO listByCategoryId(Long categoryId) { // 组装查询条件分类id 启售状态 Dish dish new Dish(); dish.setCategoryId(categoryId); dish.setStatus(StatusConstant.ENABLE); // 查询菜品列表 ListDish dishList dishMapper.list(dish); // 遍历为每个菜品查询对应的口味 ListDishVO dishVOList new ArrayList(); for (Dish d : dishList) { DishVO dishVO BeanUtils.copyProperties(d, DishVO.class); ListDishFlavor flavors dishFlavorMapper.getByDishId(d.getId()); dishVO.setFlavors(flavors); dishVOList.add(dishVO); } return dishVOList; } }这段代码在功能上是没有问题的但存在一个明显的性能隐患标准的N1查询。先查一次菜品主表再对每个菜品查一次口味表。一个分类下有十道菜就等于11次数据库查询。这在缓存缺省时是很大的负担。3.2 加Cacheable注解后的效果改造其实就一步在方法上加上CacheableCacheable(cacheNames dish, key #categoryId) public ListDishVO listByCategoryId(Long categoryId) { // 原有的查询逻辑不变 }仅仅加了一个注解第二次请求开始方法体就不执行了。Redis里会出现一个key为dish::1397851668261564416的数据其中1397851668261564416就是categoryId的字符串形式value是JSON数组数组中每个元素对应一个DishVO。这里的关键细节是key属性的写法。#categoryId是SpEL表达式表示从方法参数中取值。Spring Cache把所有缓存数据组织成cacheName::key的二级结构cacheName相当于业务分区key是分区内的唯一标识。实际开发中一个容易出错的地方是如果查询条件不只是categoryId还包括status或其他字段key里必须把这些条件全部拼上否则就会出现不同条件共用同一个缓存key的问题。比如status字段被漏掉第一次查到的是启售菜品并缓存了之后管理端下架了部分菜品用户端继续走旧缓存已经下架的菜还是展示在小程序里。3.3 套餐缓存的复刻套餐的缓存改造和菜品几乎一样只是换了个cacheNameCacheable(cacheNames setmeal, key #categoryId) public ListSetmeal listByCategoryId(Long categoryId) { // 查询启售套餐列表 }套餐查询和菜品查询是用户端两个完全独立的入口但是缓存设计思路一致所以用一个相同模式的代码块就能解决。这里想多说一句关于cacheName命名的习惯。很多同学写注解时不太在意名字随手写个字符串只要能跑就行。但cacheName在Redis里直接体现为key的前缀后期排查问题、清理缓存、做监控时全靠它定位。建议命名规范统一用和业务强相关的英文单词不要用简写到连自己都要猜的缩写。3.4 观察一下Redis里实际存的缓存改完后启动项目用用户端接口请求一次然后连上Redis看数据127.0.0.1:6379 keys * 1) dish::1397851668261564416 2) setmeal::1397851668261564416再用get命令看value127.0.0.1:6379 get dish::1397851668261564416如果配置了JSON序列化返回的是一串可读的JSON数组每个菜品对象的字段名、字段值一目了然。看到这个结果说明缓存已经生效。这时候再请求一次相同的接口在IDEA控制台会看到SQL语句不再打印说明请求直接被缓存拦截了。4. 缓存一致性处理业务改动后怎么同步缓存4.1 缓存之后最怕的就是数据变了缓存没变加了缓存后的第一个潜在问题就是管理端修改了菜品数据用户端还在看旧缓存。举个例子管理端把某个菜品的价格从28元改成32元数据库里的价格已经变了但Redis里缓存着的DishVO还是28元。用户端小程序显示的还是旧价格用户下单时按32元扣费就形成了一场小小的资损事故。所以加缓存不是加个Cacheable就完了必须同步考虑数据变更时的缓存清理策略。这是缓存改造的真正重心也是苍穹外卖day07这天的核心难点。4.2 缓存更新策略的取舍业界有两种常规策略先更新数据库再删除缓存或者先删除缓存再更新数据库。第一种“先更新数据库再删除缓存”的风险是在更新数据库和删除缓存之间的时间窗口内如果有并发读请求会命中旧缓存返回旧数据。第二种“先删缓存再更新数据库”的风险是在删除缓存和更新数据库之间的时间窗口内有并发读请求访问发现缓存没有就会把数据库的旧数据读到缓存里然后数据库才更新导致缓存里长期存着旧数据。两种方案各有问题都需要通过缓存过期时间兜底。在苍穹外卖这个项目里处理方式比较简单直接使用CacheEvict标注在管理端的增删改方法上每次操作后直接删除对应缓存让下一次用户端请求重新查库、重新构建缓存。4.3 CacheEvict的几种使用姿势单个菜品的修改CacheEvict(cacheNames dish, key #id) public void updateById(Dish dish) { dishMapper.updateById(dish); }根据分类清理CacheEvict(cacheNames dish, key #categoryId) public void updateByCategoryId(Long categoryId) { // 修改分类 }如果涉及多个菜品的批量变动比如套餐内菜品变更、菜品起售停售切换很难确定影响哪些categoryId时可以直接用allEntries清空整个dish分区CacheEvict(cacheNames dish, allEntries true) public void startOrStop(Integer status, Long id) { dishMapper.updateStatus(status, id); }allEntriestrue的意思是不指定具体key把该cacheName下的所有缓存全部清除。虽然粗暴但是在菜品批量操作、涉及分类范围不确定时这是最不容易出错的清理方式。缓存重建的开销无非就是下次查询时多查几次库这个成本远比“缓存残留旧数据”事故的损失小。4.4 一个真实场景的完整链路蘑菇在本项目里遇到过一个场景管理端把菜品的某个分类从“热销”改到“新品”分类变了categoryId的查询结果理论上应该从“热销”分类缓存中消失出现在“新品”分类缓存中。但如果只在菜品Service的updateById方法加了CacheEvict(cacheNames dish, key #id)那就出大事了——key是菜品id可用户端查询时用的key是categoryId这两个key完全对不上。改了菜品所属分类后旧的categoryId缓存里依旧有这个菜品新的categoryId缓存在查询时也重建了客户端看到的是同一个菜品出现在两个分类里。这个问题的根因是缓存key的设计必须和查询维度对齐清理时同样对齐。修改操作影响的不是菜品id这一个维度而是它涉及的所有查询维度。苍穹外卖的场景相对简单但如果你排查问题遇到修改数据后缓存不生效反思一下是不是这个原因。4.5 事务与缓存注解的执行顺序还有一个隐藏比较深的问题事务和缓存注解同时存在时执行顺序会怎样。Spring的执行逻辑是这样的如果方法上同时存在Transactional和CacheEvict默认情况下缓存清理发生在事务提交之前。也就是说如果事务提交失败回滚了但缓存已经被清除了就会变成“数据库没变缓存却被清了”下次查询重建缓存数据依然还是旧数据并没有资损只是白白多了一次清缓存操作。更麻烦的情况是事务提交成功但缓存清理异常。老版本的Spring Cache默认会吞掉缓存异常缓存没删掉数据库却变了就会留下脏缓存。我在项目里的做法是对于重要的写操作不依赖注解清缓存而是在事务提交后主动调用一个缓存清理组件。不过对于苍穹外卖这种教学级项目用CacheEvict再加上TTL兜底就够了真正的高一致性场景需要更复杂的方案不在day07的范围内。5. 缓存改造后暴露的四个经典问题5.1 缓存穿透查询不存在的数据缓存直接被打穿上线后第一个遇到的问题是用户端开始出现部分接口响应被拖慢的情况。排查后确认是缓存穿透。缓存穿透是指查询的数据在数据库里根本不存在导致每次请求都会绕过缓存直接查询MySQL。比如用户端传入一个不存在的categoryId或者菜品的status被改成停售查询条件天然查不到数据缓存也就永远不会被写入请求全部打到数据库。解决方式分两层第一层是业务校验在Controller层对categoryId进行合法性校验不存在的id直接返回不进入service查询。这个最简单也最有效。第二层是Spring Cache层面的兜底。有两种办法一是缓存空值给缓存一个很短的TTL比如5秒二是启用synctrue对同一个key实现请求级别的锁避免热点key同时失效时大量并发请求全部打到数据库Cacheable(cacheNames dish, key #categoryId, sync true) public ListDishVO listByCategoryId(Long categoryId) { // 查询逻辑 }synctrue的作用是当多个线程同时访问同一个key且缓存未命中时只允许一个线程执行方法体并把结果加载到缓存其他线程等待。这能解决“缓存击穿”的一部分问题也就是某个热点key失效瞬间的并发冲击。5.2 缓存击穿热点数据同时失效压力瞬间打满缓存击穿和缓存穿透经常被搞混。击穿指的是某个非常热门的key失效了大量请求同时发现缓存没命中于是一拥而上全去查数据库。穿透是查询一个根本不存在的key压根没有缓存可查。在苍穹外卖的场景里最典型的就是晚高峰时段“热门分类”的菜品缓存刚好过期。整个分类下的菜品都是高热度数据缓存一失效几百个并发请求同时执行查询菜品和口味的方法数据库连接池直接被占满。synctrue可以解决单节点下的击穿问题因为它保证同一个key在本地JVM维度内只有一个线程去加载数据。但需要注意Spring Cache的sync是JVM级别的锁如果服务是多个实例部署每个实例各有一把锁并发击穿还是会打到数据库。生产环境的通用方案是把“本地锁”升级成“分布式锁”比如用Redis的setnx实现全局锁。不过在day07阶段项目是单机部署synctrue完全够用这也是我为什么推荐先调整一个属性就行的原因。过早引入分布式锁会增加很多复杂度对当前阶段性价比不高。5.3 缓存雪崩所有缓存同时失效雪崩问题是因为所有缓存的TTL配置了一样长的时间导致大量key在同一时间段内集体过期数据库在那一瞬间承受了超出平时的请求量。Spring Cache的entryTtl默认是全局统一的30分钟意味着所有菜品、套餐缓存都在同一时刻失效正好重叠时数据库压力会瞬间飙升。解决方式有两种第一种是构造CacheManager时针对不同的cacheName设置不同的TTL比如菜品30分钟、套餐10分钟让失效时间错开。第二种更加实用给每种cacheName的TTL加上随机偏移量避免集体失效。如果所有菜品缓存的TTL都是固定值它们会在大约同一时间集体过期产生周期性雪崩加上随机属性后失效时间分散压力就被削平了。5.4 序列化问题缓存里的旧数据反序列化失败这个问题是在一次联调时暴露的。场景是这样的项目里有一个菜品实体类字段定义是BigDecimal price后来因为精度问题改成了Integer类型。改完之后再启动服务从Redis里读缓存直接报ClassCastException或者反序列化异常。原因是Redis里旧缓存的JSON结构还保留了BigDecimal的数值格式新代码用Integer去反序列化就出问题了。这类问题在开发环境不出现因为开发时缓存经常被清空但到了测试或生产环境旧缓存数据还在改动字段类型后就会出现。解决方式没有技巧就是改字段时记得清一下Redis里的旧缓存。另外一种做法是给Redis key追加版本号比如dish:v2::1397851668261564416版本升级时自动过期旧key避免新旧数据格式混在一起。这个技巧在项目快速迭代期特别有用每次实体结构变更把cacheName后面拼一个版本号直接规避掉隐患。6. 这天的改造对项目后续开发的影响day07做完缓存改造之后整个项目的代码里到处都有了缓存的影子。这个影响不只是性能层面的更重要的是它改变了后续每个模块的开发思维。后面写购物车、订单等功能时哪些接口该走缓存哪些接口必须直查数据库判断标准会清晰很多。所有读多写少、数据一致性要求不那么极端的数据优先考虑缓存所有涉及金额计算、库存扣减、状态流转的写操作永远不要碰缓存更不能基于缓存的值做业务判断。另外要说一下这部分改造的代码虽然在课程里只体现了几个注解但真正要理解透建议自己动手做两件事第一件事是把缓存翻出来看看把Redis里的key、value用命令行看一遍搞清楚每个注解在Redis层面到底做了什么第二件事是故意在管理端改一条菜品数据观察Redis里的旧缓存什么时候消失、什么时候重建、新缓存里的数据是什么。这两件事做完缓存相关的原理会比看十遍视频更深刻。同学如果你也在这个项目day07阶段停留过我的建议是缓存一致性的测试多写几组别只验证“改价格能生效”把改分类、改状态、批量删除这三种场景都测一遍。这三个场景的bug也是在真实项目里最容易踩的坑提前踩一遍反而是好事。
写到第七天苍穹外卖这个项目的主干其实已经基本成型了后端能启动员工端能管理分类和菜品用户端能登录、能看店、能看菜单。但如果你真的自己点开过小程序页面或者拿压测工具跑过一遍会发现一个很现实的问题——用户每次打开菜单都要从MySQL里把菜品数据查一遍。数据量不大但架不住请求多到饭点高峰那一下数据库连接数能飙得让人心虚。day07这天的任务就是把用户端查询这条链路从“能跑”变成“扛得住”。核心手段是给高频查询接口加缓存用的技术栈是Spring Cache加Redis。这篇我就把这一天的改造过程、注解选择、缓存一致性处理和上线后的几个经典坑完整拆开讲一遍给正在跟这个项目的同学一个参考。1. day07到底在做什么用户端查询链路梳理1.1 为什么在这个节点引入缓存苍穹外卖做到第六天用户端的微信登录、店铺状态、分类查询、菜品浏览都已经打通。这时项目整体处于一个“功能齐全但性能裸奔”的状态。拿用户打开小程序点外卖这个动作举例背后的接口调用路径大概是这样的进入首页查店铺营业状态进入点餐页按分类加载菜品列表点击某个分类再查一次该分类下的菜品和套餐每次切换分类都会重新查询数据库。这些接口有一个共同特征读多写少。菜品数据在管理端被修改的频率很低但用户端的读取频率极高而且早晚高峰的请求集中度非常明显。如果没有缓存每次读取都要走一遍“建立连接、执行SQL、封装结果”的完整流程数据库压力大响应时间也容易波动。到这个节点引入缓存不是因为之前的代码有问题而是因为项目已经到了需要区分“写路径”和“读路径”的阶段。管理端负责维护数据用户端负责消费数据中间用一层缓存把两侧隔开这是业务系统最经典的架构演进路径。1.2 需要优先加缓存的接口范围day07盯住的是用户端的高频读接口具体来说就是用Cache模块下这几个接口接口数据特征不缓存时的问题根据分类id查询菜品列表查询频繁数据基本不变每次全量查库根据分类id查询套餐列表查询频繁数据基本不变每次全量查库根据id查询菜品详情点餐页高频访问单行查询也要建连这里有个容易被忽略的点套餐列表和菜品列表的查询参数看似只有categoryId但实际查询条件还包括status字段只查启售状态的商品。这个细节直接关系到后面缓存key的设计如果key里漏掉查询条件就会出现缓存了禁用菜品的问题这个我放到第三章详细说。1.3 缓存选型的现实依据很多同学会问为什么不直接手写RedisTemplate操作而是引入Spring Cache我在确认方案之前也对比过。手写Redis缓存的好处是控制力强可以对每个key精确管理过期时间但坏处是代码侵入性大一个查询方法里要塞进大量的序列化、反序列化和key拼接逻辑而且缓存清理逻辑散落在业务代码里很容易漏。Spring Cache则是把缓存操作抽象成注解业务方法只需要关心自己的逻辑缓存行为通过Cacheable这些注解声明式地附加到方法上侵入性小代码可读性高。对于苍穹外卖这种业务复杂度不高的项目Spring Cache是完全够用的而且后面维护起来省心。2. Spring Cache和Redis是怎么配合工作的2.1 Spring Cache解决的三个核心问题Spring Cache是Spring框架提供的一套缓存抽象它解决的核心问题有三个第一缓存操作的声明式注入。开发者在方法上标注注解框架在方法执行前检查缓存执行后写入缓存开发者不需要关心底层缓存API。第二缓存实现的可插拔。它定义了一套统一接口CacheManager底层可以用Redis、Ehcache、Caffeine甚至是一个ConcurrentHashMap来当缓存实现。切换缓存中间件时业务代码完全不用改。第三缓存异常不影响主流程。默认情况下缓存读写抛出的异常会被吞掉保证核心业务不因为缓存故障而中断。但要知道Spring Cache本身并不实现存储它只是给你提供“操作缓存”的门面。真正把数据存下来的是RedisCacheManager这个具体实现它负责告诉Spring Cache“拿Redis当存储介质key怎么序列化value怎么序列化过期时间多久”。2.2 Spring Cache常用的三个注解这一天的开发主要用到三个注解先把语义理清楚Cacheable方法执行前先查缓存命中就直接返回缓存结果不执行方法体未命中就执行方法体并把返回值放入缓存。CachePut方法执行后把返回值更新到缓存。不查缓存每次都执行方法。CacheEvict方法执行后删除指定的缓存。这中间最容易弄混的是Cacheable和CachePut。简单记前者是“读的时候用”后者是“写的时候顺手把缓存更新掉”。而CacheEvict的逻辑最简单粗暴——数据变了直接删缓存等下次查询时再重建。2.3 RedisCacheManager配置的几个关键点Spring Boot 2.x版本下需要在配置类里手动构建RedisCacheManager。直接看代码Configuration EnableCaching public class RedisCacheConfig { Bean public CacheManager cacheManager(RedisConnectionFactory connectionFactory) { RedisCacheConfiguration defaultConfig RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30)) .serializeKeysWith( RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer()) ) .serializeValuesWith( RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()) ) .disableCachingNullValues(); return RedisCacheManager.builder(connectionFactory) .cacheDefaults(defaultConfig) .build(); } }这里有三个必须解释清楚的设计缺一个后面都会踩坑。第一个是key序列化器用StringRedisSerializervalue序列化器用GenericJackson2JsonRedisSerializer。如果不指定Spring Cache默认使用JDK序列化Redis里存的会是带类型头的二进制数据肉眼几乎没法排查。更重要的是JDK序列化要求缓存对象实现Serializable接口一旦实体类忘记实现运行期直接报错。改成JSON序列化Redis里的value是正常可读的JSON字符串排查问题方便很多。第二个是entryTtl默认设置了30分钟。过期时间在这里作为兜底机制存在就算后面缓存清理逻辑出错最坏情况下数据也会在30分钟后自动失效数据库会重新加载到最新数据。这个TTL设置是缓存系统最后一道安全网。第三个是disableCachingNullValues()。这个选项的作用是禁止缓存null值。背后有一个很微妙的考量如果查询数据库返回null框架会认为“缓存穿透的产物”而不是一个正常的缓存值。开启这个选项后空值不缓存防止大量非法请求把空结果也缓存下来把Redis打成“空数据仓库”。3. 菜品缓存改造的完整落地过程3.1 改造前的原始查询逻辑用户端查询菜品的代码最开始是service层直接查数据库然后把实体转换成VO返回给ControllerService public class DishServiceImpl implements DishService { Autowired private DishMapper dishMapper; public ListDishVO listByCategoryId(Long categoryId) { // 组装查询条件分类id 启售状态 Dish dish new Dish(); dish.setCategoryId(categoryId); dish.setStatus(StatusConstant.ENABLE); // 查询菜品列表 ListDish dishList dishMapper.list(dish); // 遍历为每个菜品查询对应的口味 ListDishVO dishVOList new ArrayList(); for (Dish d : dishList) { DishVO dishVO BeanUtils.copyProperties(d, DishVO.class); ListDishFlavor flavors dishFlavorMapper.getByDishId(d.getId()); dishVO.setFlavors(flavors); dishVOList.add(dishVO); } return dishVOList; } }这段代码在功能上是没有问题的但存在一个明显的性能隐患标准的N1查询。先查一次菜品主表再对每个菜品查一次口味表。一个分类下有十道菜就等于11次数据库查询。这在缓存缺省时是很大的负担。3.2 加Cacheable注解后的效果改造其实就一步在方法上加上CacheableCacheable(cacheNames dish, key #categoryId) public ListDishVO listByCategoryId(Long categoryId) { // 原有的查询逻辑不变 }仅仅加了一个注解第二次请求开始方法体就不执行了。Redis里会出现一个key为dish::1397851668261564416的数据其中1397851668261564416就是categoryId的字符串形式value是JSON数组数组中每个元素对应一个DishVO。这里的关键细节是key属性的写法。#categoryId是SpEL表达式表示从方法参数中取值。Spring Cache把所有缓存数据组织成cacheName::key的二级结构cacheName相当于业务分区key是分区内的唯一标识。实际开发中一个容易出错的地方是如果查询条件不只是categoryId还包括status或其他字段key里必须把这些条件全部拼上否则就会出现不同条件共用同一个缓存key的问题。比如status字段被漏掉第一次查到的是启售菜品并缓存了之后管理端下架了部分菜品用户端继续走旧缓存已经下架的菜还是展示在小程序里。3.3 套餐缓存的复刻套餐的缓存改造和菜品几乎一样只是换了个cacheNameCacheable(cacheNames setmeal, key #categoryId) public ListSetmeal listByCategoryId(Long categoryId) { // 查询启售套餐列表 }套餐查询和菜品查询是用户端两个完全独立的入口但是缓存设计思路一致所以用一个相同模式的代码块就能解决。这里想多说一句关于cacheName命名的习惯。很多同学写注解时不太在意名字随手写个字符串只要能跑就行。但cacheName在Redis里直接体现为key的前缀后期排查问题、清理缓存、做监控时全靠它定位。建议命名规范统一用和业务强相关的英文单词不要用简写到连自己都要猜的缩写。3.4 观察一下Redis里实际存的缓存改完后启动项目用用户端接口请求一次然后连上Redis看数据127.0.0.1:6379 keys * 1) dish::1397851668261564416 2) setmeal::1397851668261564416再用get命令看value127.0.0.1:6379 get dish::1397851668261564416如果配置了JSON序列化返回的是一串可读的JSON数组每个菜品对象的字段名、字段值一目了然。看到这个结果说明缓存已经生效。这时候再请求一次相同的接口在IDEA控制台会看到SQL语句不再打印说明请求直接被缓存拦截了。4. 缓存一致性处理业务改动后怎么同步缓存4.1 缓存之后最怕的就是数据变了缓存没变加了缓存后的第一个潜在问题就是管理端修改了菜品数据用户端还在看旧缓存。举个例子管理端把某个菜品的价格从28元改成32元数据库里的价格已经变了但Redis里缓存着的DishVO还是28元。用户端小程序显示的还是旧价格用户下单时按32元扣费就形成了一场小小的资损事故。所以加缓存不是加个Cacheable就完了必须同步考虑数据变更时的缓存清理策略。这是缓存改造的真正重心也是苍穹外卖day07这天的核心难点。4.2 缓存更新策略的取舍业界有两种常规策略先更新数据库再删除缓存或者先删除缓存再更新数据库。第一种“先更新数据库再删除缓存”的风险是在更新数据库和删除缓存之间的时间窗口内如果有并发读请求会命中旧缓存返回旧数据。第二种“先删缓存再更新数据库”的风险是在删除缓存和更新数据库之间的时间窗口内有并发读请求访问发现缓存没有就会把数据库的旧数据读到缓存里然后数据库才更新导致缓存里长期存着旧数据。两种方案各有问题都需要通过缓存过期时间兜底。在苍穹外卖这个项目里处理方式比较简单直接使用CacheEvict标注在管理端的增删改方法上每次操作后直接删除对应缓存让下一次用户端请求重新查库、重新构建缓存。4.3 CacheEvict的几种使用姿势单个菜品的修改CacheEvict(cacheNames dish, key #id) public void updateById(Dish dish) { dishMapper.updateById(dish); }根据分类清理CacheEvict(cacheNames dish, key #categoryId) public void updateByCategoryId(Long categoryId) { // 修改分类 }如果涉及多个菜品的批量变动比如套餐内菜品变更、菜品起售停售切换很难确定影响哪些categoryId时可以直接用allEntries清空整个dish分区CacheEvict(cacheNames dish, allEntries true) public void startOrStop(Integer status, Long id) { dishMapper.updateStatus(status, id); }allEntriestrue的意思是不指定具体key把该cacheName下的所有缓存全部清除。虽然粗暴但是在菜品批量操作、涉及分类范围不确定时这是最不容易出错的清理方式。缓存重建的开销无非就是下次查询时多查几次库这个成本远比“缓存残留旧数据”事故的损失小。4.4 一个真实场景的完整链路蘑菇在本项目里遇到过一个场景管理端把菜品的某个分类从“热销”改到“新品”分类变了categoryId的查询结果理论上应该从“热销”分类缓存中消失出现在“新品”分类缓存中。但如果只在菜品Service的updateById方法加了CacheEvict(cacheNames dish, key #id)那就出大事了——key是菜品id可用户端查询时用的key是categoryId这两个key完全对不上。改了菜品所属分类后旧的categoryId缓存里依旧有这个菜品新的categoryId缓存在查询时也重建了客户端看到的是同一个菜品出现在两个分类里。这个问题的根因是缓存key的设计必须和查询维度对齐清理时同样对齐。修改操作影响的不是菜品id这一个维度而是它涉及的所有查询维度。苍穹外卖的场景相对简单但如果你排查问题遇到修改数据后缓存不生效反思一下是不是这个原因。4.5 事务与缓存注解的执行顺序还有一个隐藏比较深的问题事务和缓存注解同时存在时执行顺序会怎样。Spring的执行逻辑是这样的如果方法上同时存在Transactional和CacheEvict默认情况下缓存清理发生在事务提交之前。也就是说如果事务提交失败回滚了但缓存已经被清除了就会变成“数据库没变缓存却被清了”下次查询重建缓存数据依然还是旧数据并没有资损只是白白多了一次清缓存操作。更麻烦的情况是事务提交成功但缓存清理异常。老版本的Spring Cache默认会吞掉缓存异常缓存没删掉数据库却变了就会留下脏缓存。我在项目里的做法是对于重要的写操作不依赖注解清缓存而是在事务提交后主动调用一个缓存清理组件。不过对于苍穹外卖这种教学级项目用CacheEvict再加上TTL兜底就够了真正的高一致性场景需要更复杂的方案不在day07的范围内。5. 缓存改造后暴露的四个经典问题5.1 缓存穿透查询不存在的数据缓存直接被打穿上线后第一个遇到的问题是用户端开始出现部分接口响应被拖慢的情况。排查后确认是缓存穿透。缓存穿透是指查询的数据在数据库里根本不存在导致每次请求都会绕过缓存直接查询MySQL。比如用户端传入一个不存在的categoryId或者菜品的status被改成停售查询条件天然查不到数据缓存也就永远不会被写入请求全部打到数据库。解决方式分两层第一层是业务校验在Controller层对categoryId进行合法性校验不存在的id直接返回不进入service查询。这个最简单也最有效。第二层是Spring Cache层面的兜底。有两种办法一是缓存空值给缓存一个很短的TTL比如5秒二是启用synctrue对同一个key实现请求级别的锁避免热点key同时失效时大量并发请求全部打到数据库Cacheable(cacheNames dish, key #categoryId, sync true) public ListDishVO listByCategoryId(Long categoryId) { // 查询逻辑 }synctrue的作用是当多个线程同时访问同一个key且缓存未命中时只允许一个线程执行方法体并把结果加载到缓存其他线程等待。这能解决“缓存击穿”的一部分问题也就是某个热点key失效瞬间的并发冲击。5.2 缓存击穿热点数据同时失效压力瞬间打满缓存击穿和缓存穿透经常被搞混。击穿指的是某个非常热门的key失效了大量请求同时发现缓存没命中于是一拥而上全去查数据库。穿透是查询一个根本不存在的key压根没有缓存可查。在苍穹外卖的场景里最典型的就是晚高峰时段“热门分类”的菜品缓存刚好过期。整个分类下的菜品都是高热度数据缓存一失效几百个并发请求同时执行查询菜品和口味的方法数据库连接池直接被占满。synctrue可以解决单节点下的击穿问题因为它保证同一个key在本地JVM维度内只有一个线程去加载数据。但需要注意Spring Cache的sync是JVM级别的锁如果服务是多个实例部署每个实例各有一把锁并发击穿还是会打到数据库。生产环境的通用方案是把“本地锁”升级成“分布式锁”比如用Redis的setnx实现全局锁。不过在day07阶段项目是单机部署synctrue完全够用这也是我为什么推荐先调整一个属性就行的原因。过早引入分布式锁会增加很多复杂度对当前阶段性价比不高。5.3 缓存雪崩所有缓存同时失效雪崩问题是因为所有缓存的TTL配置了一样长的时间导致大量key在同一时间段内集体过期数据库在那一瞬间承受了超出平时的请求量。Spring Cache的entryTtl默认是全局统一的30分钟意味着所有菜品、套餐缓存都在同一时刻失效正好重叠时数据库压力会瞬间飙升。解决方式有两种第一种是构造CacheManager时针对不同的cacheName设置不同的TTL比如菜品30分钟、套餐10分钟让失效时间错开。第二种更加实用给每种cacheName的TTL加上随机偏移量避免集体失效。如果所有菜品缓存的TTL都是固定值它们会在大约同一时间集体过期产生周期性雪崩加上随机属性后失效时间分散压力就被削平了。5.4 序列化问题缓存里的旧数据反序列化失败这个问题是在一次联调时暴露的。场景是这样的项目里有一个菜品实体类字段定义是BigDecimal price后来因为精度问题改成了Integer类型。改完之后再启动服务从Redis里读缓存直接报ClassCastException或者反序列化异常。原因是Redis里旧缓存的JSON结构还保留了BigDecimal的数值格式新代码用Integer去反序列化就出问题了。这类问题在开发环境不出现因为开发时缓存经常被清空但到了测试或生产环境旧缓存数据还在改动字段类型后就会出现。解决方式没有技巧就是改字段时记得清一下Redis里的旧缓存。另外一种做法是给Redis key追加版本号比如dish:v2::1397851668261564416版本升级时自动过期旧key避免新旧数据格式混在一起。这个技巧在项目快速迭代期特别有用每次实体结构变更把cacheName后面拼一个版本号直接规避掉隐患。6. 这天的改造对项目后续开发的影响day07做完缓存改造之后整个项目的代码里到处都有了缓存的影子。这个影响不只是性能层面的更重要的是它改变了后续每个模块的开发思维。后面写购物车、订单等功能时哪些接口该走缓存哪些接口必须直查数据库判断标准会清晰很多。所有读多写少、数据一致性要求不那么极端的数据优先考虑缓存所有涉及金额计算、库存扣减、状态流转的写操作永远不要碰缓存更不能基于缓存的值做业务判断。另外要说一下这部分改造的代码虽然在课程里只体现了几个注解但真正要理解透建议自己动手做两件事第一件事是把缓存翻出来看看把Redis里的key、value用命令行看一遍搞清楚每个注解在Redis层面到底做了什么第二件事是故意在管理端改一条菜品数据观察Redis里的旧缓存什么时候消失、什么时候重建、新缓存里的数据是什么。这两件事做完缓存相关的原理会比看十遍视频更深刻。同学如果你也在这个项目day07阶段停留过我的建议是缓存一致性的测试多写几组别只验证“改价格能生效”把改分类、改状态、批量删除这三种场景都测一遍。这三个场景的bug也是在真实项目里最容易踩的坑提前踩一遍反而是好事。
)
)
