核心系统如何实现核心数据的缓存预热？

日期：2026-07-11
标签：#面试 #八股 #后端 #缓存预热 #系统设计 #场景题

一句话答案

根据历史访问和业务规则生成核心 Key 清单，在发布或扩容前分批、限速、可校验地加载缓存，并保留按需回填、请求合并和数据库保护作为冷启动兜底。

面试口语版

先定义要预热的数据和新鲜度：可从历史 Top K、活动名单、配置和核心字典生成 Manifest，包含版本、Key、预期数量和校验信息。实例启动时不能阻塞式全量加载，应由预热任务按分片限速读取事实源，批量写 Redis/本地缓存，设置 TTL 随机抖动并记录成功率。新实例 Readiness 可等最低核心集完成后再接流量，剩余数据后台加载。预热过程中保护数据库，失败可重试；对于遗漏 Key，读路径仍使用 SingleFlight 按需回填。发布新版本用命名空间/版本 Key 预热完成后再切换，便于回滚。

预热流程

flowchart LR
  A[生成热点Manifest] --> B[分片限速读取事实源]
  B --> C[批量写缓存]
  C --> D[校验数量版本抽样]
  D --> E[灰度开放流量]
  E --> F[按需回填与持续监控]

关键细节

预热本身可能打垮数据库或网络，必须限速和错峰。
不要把所有数据都当核心缓存，容量按字节和命中收益评估。
TTL 加抖动，避免预热数据未来同一时刻集中失效。
监控预热进度、失败数、命中率、回源 QPS 和缓存水位。

面试官追问

如何判断哪些是核心数据？
新版本数据结构变化如何无缝预热？
预热期间数据库压力过大怎么办？

面试官追问参考答案

1. 如何判断哪些是核心数据？

结合历史窗口访问频率、峰值 QPS、缺失时业务影响和即将发生的活动，生成分级清单。核心不等于最热，还包括配置、权限、路由等缺失会阻断业务的小数据；清单应持续更新而非人工永久固定。

2. 新版本数据结构变化如何无缝预热？

使用带版本的 Key 命名空间，后台把新结构完整预热并校验，应用灰度支持双读或优先新版本，确认后原子切换版本指针。旧缓存保留一个回滚窗口，再异步清理。

3. 预热期间数据库压力过大怎么办？

按数据库 CPU、复制延迟和连接水位动态限速，优先从只读副本、快照或离线文件加载，批量读取并分时段执行。若水位超阈值自动暂停，线上请求优先，剩余 Key 依赖按需回填。

学习清单

能设计 Manifest、分片限速和版本切换。
理解预热失败与冷启动兜底。