这里写自定义目录标题一、缓存预热Q1为什么需要?Q2哪些适合二、缓存预热常见的方式1.应用启动时预热PostConstruct 和 ApplicationReadyEvent 的使用对比2.定时任务预热3.活动开始前主动预热4.人工/后台触发预热5.根据历史访问数据预热热点6.预测未来热点进行预热7.缓存失效前主动刷新三、实际项目中的缓存预热解决方案1.常见的解决方案2.预热中出现的缓存雪崩、缓存击穿3.缓存预热失败4.多个实例重复预热一、缓存预热缓存预热Cache Warm-up指的是在用户真正访问数据之前提前把后续可能频繁访问的数据加载到缓存中。Q1为什么需要?正常的缓存用到了再缓存即第一次请求 - 缓存没有数据 - 查数据库 - 写入缓存 - 返回结果。后续请求直接查缓存这种方式叫做懒加载本质是先访问 → 再缓存缓存预热是系统启动 / 活动开始 / 流量到来之前 - 提前查数据 - 写入缓存这样用户请求到来时候直接命中缓存缓存预热最主要解决的是缓存刚开始为空时大量请求直接访问后端存储的问题。缓存预热的目的是降低第一次访问的响应时间防止系统启动时数据库压力突然增大应对可预测的流量高峰。Q2哪些适合缓存预热适合“读多写少、访问频繁、热点可预测、冷启动压力较大”的业务数据。适合使用缓存预热高频访问的数据、热点可以提前预测、系统启动后马上会被访问的数据、数据变化不频繁、数据库查询成本比较高的数据。不适合全量预热数据量特别大、访问频率非常低、热点无法预测、数据变化非常频繁、每个用户完全不同的数据。二、缓存预热常见的方式1.应用启动时预热应用启动的时候主动把一批固定数据加载进缓存。ComponentpublicclassCacheWarmUp{EventListener(ApplicationReadyEvent.class)publicvoidwarmUp(){// 1. 查询数据库ListCategorycategoriescategoryMapper.selectList(null);// 2. 写入缓存redisTemplate.opsForValue().set(category:list,categories);}}EventListener(ApplicationReadyEvent.class)监听 Spring Boot 应用启动完成事件。当 Spring BootSpring 容器初始化完成Bean 基本创建完成应用已经准备完成之后会发布一个ApplicationReadyEvent 此时被 EventListener 修饰的方法就会执行。PostConstruct 和 ApplicationReadyEvent 的使用对比PostConstruct常用于标记方法使其在对象实例化并完成依赖注入后立即执行。它通常用于初始化逻辑例如加载配置、建立连接等。其具体逻辑如下。如果 Redis 或 MySQL出问题则会导致Bean 初始化失败从而导致 Spring Boot 启动失败Bean 创建 ↓ 依赖注入 ↓ PostConstruct ↓ 查询数据库 ↓ 访问 Redis ↓ 加载缓存 ↓ Bean 初始化结束EventListener(ApplicationReadyEvent.class)其中的EventListener 注解用于监听应用程序事件。它可以标记一个方法使其成为事件监听器用于处理特定类型的事件。其执行逻辑如下这种方法可以先让 Spring Boot 本身完成启动再执行非核心初始化任务。Spring Context 创建完成 ↓ 所有 Bean 初始化完成 ↓ Tomcat / Netty 等基本启动完成 ↓ ApplicationReadyEvent ↓ 缓存预热EventListener默认是同步执行的不是自动异步如果预热很重缓存预热时有流量进来而缓存还没加载完接能报错、可以加 AsyncAsyncEventListener(ApplicationReadyEvent.class)publicvoidinitCityMap(){reload();}2.定时任务预热比如一个热门商品排行榜每隔 10 分钟变化一次。Scheduled(cron0 */10 * * * ?)publicvoidrefreshHotProducts(){ListProductproductsproductService.queryHotProducts();redisTemplate.opsForValue().set(hot:products,products);}Scheduled(cron “0 */10 * * * ?”) 用于执行定时任务。这里表示每隔 10 分钟执行一次。Cron 表达式0 */10 * * * ? 可以简单理解为秒0分钟每 10 分钟小时任意日期任意月份任意星期任意3.活动开始前主动预热例如 20:00 开始秒杀可以提前在 19:50 加载秒杀商品写 RedispublicvoidwarmUpSeckill(LongproductId){ProductproductproductMapper.selectById(productId);redisTemplate.opsForValue().set(seckill:product:productId,product);}warmUpSeckill() 本身只是一个普通方法什么时候需要预热就需要什么时候调用这个方法。4.人工/后台触发预热例如运营人员准备明天推广商品 10001此时运营后台可以提供预热商品PostMapping(/cache/warm-up/{productId})publicvoidwarmUp(PathVariableLongproductId){ProductproductproductMapper.selectById(productId);redisTemplate.opsForValue().set(product:productId,product);}5.根据历史访问数据预热热点如果系统数据量非常大就不能所有数据全部预热。例如100 万商品。可以通过分析过去一段时间的访问数据找出真正的热点商品。6.预测未来热点进行预热例如新闻系统中某一篇文章访问量快速上涨 评论量快速上涨 转发量快速上涨。系统可能判断该文章即将成为热点于是提前缓存文章详情 评论列表 作者信息 推荐内容。7.缓存失效前主动刷新在缓存真正过期之前提前把它刷新。例如Redis Key TTL 30 分钟。这种方案通常叫Refresh Ahead提前刷新。适合高频热点数据、首页数据、排行榜、热门商品、对响应时间要求较高的数据。三、实际项目中的缓存预热解决方案1.常见的解决方案热点数据预热 普通数据懒加载2.预热中出现的缓存雪崩、缓存击穿缓存雪崩TTL 随机值缓存击穿分布式锁 逻辑过期3.缓存预热失败缓存预热并不一定每次都会成功。可能出现数据库异常 或者 Redis 异常 或者 网络异常。因此缓存预热需要考虑失败处理。4.多个实例重复预热在分布式系统中一个服务通常会部署多个实例。例如四个 Java 服务同时启动。每个服务都有 ApplicationReadyEvent这样导致四个实例一起查询同样的数据写同样的 Redis Key解决方案分布式锁过 Redis / Redisson 分布式锁保证同一时刻只有一个实例真正执行缓存构建。Double Check防止等待锁的线程获得锁之后再次重复查询数据库。//第一次查缓存不在Redis后尝试获取锁RLocklockredissonClient.getLock(lockKey);lock.lock();//拿不到锁就等待直到成功获取锁。try{// 第二次检查先检查Redis}finally{lock.unlock();}统一任务调度如果缓存预热逻辑比较复杂也可以不让每一个服务实例自己执行预热。而是交给统一的任务调度系统例如XXL-JOB、Quartz、ElasticJob。