题目：如何实现缓存的预热？
难度：medium
评分：⭐⭐⭐⭐☆☆☆（2/5）
所谓缓存预热就是对有感知知道会被大批量访问的内容进行提前访问,将内容加载到缓存中,防止因为缓存过期导致读取缓存时出现无缓存的问题并发去访问数据库,或者造成阻塞;预热一般是通过脚本或者计划任务执行的,另外对于长期热度的 key 可能直接会设置不过期,只有手动删除更新到时候才会将对应到缓存更新
优点：
核心目的抓到- 计划任务/脚本方法提到- 长期热点不过期思路对
不足：
❌ 遗漏预热时机（服务启动 vs 大促前）- ❌ 遗漏预热方法分类（全量/增量/按需）- ❌ 遗漏预热数据量控制（分批避免雪崩）- ❌ 遗漏预热失败处理（重试/降级/监控）- ❌ 遗漏预热顺序（依赖关系、热点优先）- ❌ 遗漏预热后监控（命中率、加载耗时）
核心考点：考察缓存预热的工程化能力，区分"时机、方法、失败处理、监控"四个维度。
知识点拆解：
与缓存击穿/雪崩的区别：
面试官您好，缓存预热我从时机、方法、失败处理、监控四个维度说。
时机：服务启动时异步加载热点数据，大促前手动触发预热脚本，缓存过期前定时刷新避免空缓存。
方法：全量加载（数据量小）、增量加载（只加载变化的）、按需加载（首次访问加载）、分布式预热（多实例分摊）。分批加载每批 100-1000 条，限流避免影响线上业务，热点优先。
数据量控制：预热速率限制在 1000 QPS 以内，避免打满 DB 和 Redis。按优先级加载，Top N 商品先加载。
失败处理：失败重试 3 次（指数退避），预热失败不影响线上（缓存未命中走 DB），失败率 >5% 告警。
预热后监控：命中率应 >90%，加载耗时、缓存大小（used_memory）都要监控，避免预热导致 OOM。
和缓存击穿/雪崩的区别：预热是主动加载（事前），击穿是被动防护（事中），击穿用互斥锁或永不过期，雪崩用过期时间随机偏移。
生产实践：大促前 1 小时启动预热脚本，分批加载 Top 1000 商品，预热完成后监控命中率。预热失败降级走 DB，不影响用户体验。