缓存预热（Cache Warm-up）的解决方案与对比-北京尧图网络

这里写自定义目录标题一、缓存预热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。

缓存预热（Cache Warm-up）的解决方案与对比

相关推荐

【Matlab】城市应急疏散仿真与评估实现

环保数据监测系统：从数据采集到可视化大屏的完整实践

vivo通信智能体：从信号拼参数到体验驱动，让手机更懂你的网络需求

更多资讯

DeFi技术解析：智能合约与金融乐高的工程实践

基于GAN的复杂背景文字修复：从掩码到对抗训练实战

【三个月 AI Agent 实战学习】Day 6：结构化输出（JSON）—— 让模型与代码无缝协作

YOLOv5+ArcFace：从人脸检测到身份识别的完整改进实践

Flutter与HarmonyOS 6.0构建旅行记录应用类型选择器

毕业设计之微信小程序酒店预约管理系统

今日更新

51单片机开环控制磁阻传感器的硬件匹配与代码实现

AI Agent安全操作数据库：SQL注入防御与参数化查询实战

Android逆向实战：还原激励类App签到接口的签名算法

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？