预计算与预热：让系统“开门就是热乎的”

可视化演示

动态展示预计算三阶段流程、三种预热模式、冷热延迟对比与缓存失效机制。

预热思想起源

你经营一家面馆，每天中午客人蜂拥而至。如果客人点单后才开始揉面、熬汤、烧水，第一波客人大概率会等崩溃。聪明的做法是：清晨就把高汤熬好、面团醒好、灶火点燃——客人进门，一切就绪。这就是预热的本质：把“将来一定用得上”的昂贵工作，提前到“用户还不着急”的时候完成。

在计算机世界里，“揉面”就是昂贵的计算，“高汤”就是计算结果。一个 Web 服务的推荐接口，可能要聚合用户行为、商品库、实时特征，计算量巨大。如果每个用户第一次点击时都现场算一遍，服务立刻被压垮。预计算与预热的思路是：在流量到达前，把热门推荐结果提前算好放进缓存，用户访问时直接取用。

这套思想的核心是“预期驱动执行”。系统通过分析历史流量、业务节奏和用户行为，提前判断哪些数据会被高频访问，然后主动出击。预热的收益是立竿见影的：响应时间从秒级降到毫秒级，系统吞吐量提升数倍，用户体验从“卡顿”变为“丝滑”。

离线批处理预热

回到面馆场景。最稳妥的备菜方式，是每天凌晨客流最少的时段，把当天所有菜品提前备好：高汤熬制三小时、红烧肉焖两小时、小菜切好分装。这就是离线批处理预热——在业务低峰期，集中力量完成大规模预计算，把结果写进缓存。

技术实现上，离线批处理通常依托定时任务系统。业务方定义一个任务：每天凌晨 2 点，读取全量商品数据和近 7 天用户行为数据，通过 Spark 或 MapReduce 批量计算热门榜单、推荐候选集、聚合统计指标，将结果写入 Redis 或本地缓存。这个模式的优势是简单可靠，计算过程不干扰线上服务，适合那些数据变化不频繁、但计算量巨大的场景。

离线批处理的数学模型可以用“时间换空间”来刻画。设 $T_{compute}$ 为某数据的全量计算耗时，$T_{serve}$ 为从缓存读取该数据的耗时，则预热带来的单次访问收益为 $T_{compute} - T_{serve}$。若系统在预热后服务了 $N$ 次请求，则总收益为：

离线批处理的工程要点在于任务编排。你需要确保批处理任务在流量低峰期完成，且与线上服务错峰运行，避免资源争抢。另一个关键点是全量覆盖——批处理产出的结果必须覆盖所有可能被访问的数据，否则还是会落到冷路径上。

增量预计算

离线批处理虽然简单，但有一个致命弱点：数据是“定时更新”的，存在窗口期。假设你每天凌晨 2 点备菜，但上午 10 点突然来了一个爆款菜品的紧急订单，客人在 10:05 就要吃到——你怎么办？显然不能等到第二天。于是你需要增量预计算：随时捕捉变化，立刻更新对应的“菜品”。

增量预计算的核心是Change Data Capture（CDC）机制。系统监听数据库的 binlog 或消息队列中的变更事件，当某条商品数据被修改、某个用户产生了新行为，就触发一次小规模的增量计算，只更新受影响的缓存条目。比如一个电商平台的“热销榜”，每天全量重算一次，但每次有用户下单，就对对应商品的销量计数加一，实时更新榜单排序。

增量预计算的资源消耗模型与全量批处理截然不同。设全量计算复杂度为 $O(N)$，其中 $N$ 为数据总量；增量计算复杂度为 $O(\Delta N)$，其中 $\Delta N$ 为变化的数据量。由于 $\Delta N \ll N$，增量计算的开销远小于全量计算。如果数据变化服从泊松过程，到达率为 $\lambda$，则单位时间内的增量计算总开销为：

增量预计算的工程实现要处理好“新旧结果合并”。推荐的候选集可能是并集操作，排行榜是排序合并，计数器直接累加。如果合并逻辑出错，缓存中的数据会产生“脏读”，比如把下架的旧商品推荐给用户。因此，增量更新必须配合版本号或时间戳校验。

按需触发模式

有了离线批处理和增量预计算，是否就万事大吉？不对，还有一类数据是“不确定会不会被访问”的。比如某个长尾商品，可能一个月才被浏览一次。如果也让批处理任务去预计算它的推荐结果，纯属浪费。这时就用到了按需触发模式——客人点了这道菜，才现做；但做完之后，这道菜温着，下一个客人点同样菜就能直接上。

按需触发模式也叫惰性加载（Lazy Loading）。第一次请求到达时，系统发现缓存中不存在该数据，于是触发一次实时计算，将结果写入缓存并设置过期时间，后续相同请求直接命中缓存。这个模式的关键在于并发控制：如果同一时刻有 100 个请求发现缓存未命中，不能让 100 个请求都去执行计算，否则缓存会被打穿。

解决并发雪崩的标准方案是分布式锁。第一个请求获取锁，执行计算，写入缓存后释放锁；其余请求等待锁释放后，直接读取缓存。这个过程的状态转移可以用马尔可夫链建模。设缓存状态为 $S \in \{ \text{空}, \text{计算中}, \text{就绪}, \text{过期} \}$，状态转移概率为 $P_{ij}$。缓存命中的稳态概率为：

按需触发模式把“预计算”和“实时计算”结合得恰到好处。对于高频访问的数据，第一次计算只产生一次冷启动成本，后续全部命中。对于低频数据，无需预计算，避免浪费。你需要在服务启动时，预加载一批“高概率被访问”的数据作为兜底，剩下交给按需逻辑。

预热时机选择

备菜备得早，菜品容易凉；备得晚，客人等不及。预热的时机选择，直接决定了缓存数据的“新鲜度”和“及时性”。面馆老板会在每天 10:30 把午市的菜品备齐，因为我们知道午市 11:30 开始流量暴涨——这就是预热时机的核心逻辑：对齐业务节奏。

工程上有三种典型的预热时机策略。第一种是固定时间窗预热：在每日流量低峰期（如凌晨 2-4 点）执行大规模预热，适合业务节奏规律的场景，如资讯类 App 的早间版推送。第二种是发布前梯度预热：在服务上线前，先启动 JVM 并加载核心缓存，再用影子流量逐步放量，让服务在承接真实用户流量前达到“热状态”。第三种是预测算法触发预热：基于时间序列预测模型（如 ARIMA、Prophet）预测未来流量峰值，在峰值前自动触发预热。

梯度预热的工程数学模型，可以用服务能力恢复曲线来描述。服务在启动后 $t$ 秒时，缓存命中率 $H(t)$ 由冷启动状态逐渐收敛到稳态命中率 $H_\infty$，经验模型为：

其中 $\tau$ 是预热时间常数，反映系统达到热状态的速度。$\tau$ 越大，预热所需时间越长。在这个公式的指导下，你可以估算：要在流量峰值时刻 $T_{peak}$ 达到 95% 的稳态命中率，需要在 $T_{peak} - 3\tau$ 之前启动预热。

需要警惕的是，预热时机选错会带来两种极端后果。预热太早，数据在高峰期前就已过期，等于白做；预热太晚，流量已经冲进来，系统被打穿后缓存仍在慢慢构建。因此，成熟的系统会同时使用多种预热策略，互为补充。

缓存容量规划

面馆的冰箱容量有限。备菜太多，放不下，食材不新鲜；备菜太少，高峰期不够卖。缓存容量规划，就是在“命中率”和“成本”之间找到最优平衡点。你不可能把整个数据库都装进 Redis，只能装下最有价值的“热数据”。

容量规划的第一步是评估热数据占比。根据二八定律，通常 20% 的热数据承担了 80% 的访问量。你需要用访问日志分析出哪些 Key 高频访问，然后为缓存设置容量，恰好装下这批热数据。如果热数据集合超过缓存容量，就会出现频繁的缓存淘汰和重建，命中率骤降。

容量与命中率的关系可以用“缓存收益模型”刻画。设缓存容量为 $C$，数据总规模为 $D$，访问频率服从 Zipf 分布，则缓存命中率的近似公式为：

这个公式直观地说明：在 Zipf 分布下，命中率与容量的对数成正比。把容量从 100 提高到 1000，命中率提升约 $\ln(10)/\ln(D)$，但内存成本增加了 10 倍。因此，你需要用“边际命中率”来决策：每增加 1GB 缓存能提升多少命中率？当边际收益小于硬件成本时，就停止扩容。

容量规划还要考虑淘汰策略。常见的 LRU（最近最少使用）适合热点集中的场景，LFU（最不经常使用）适合访问频率差异大的场景，FIFO（先进先出）则适合生命周期短暂的数据。选错淘汰策略，热数据会被冷数据挤出缓存，命中率骤降。你可以用模拟流量回放来测试不同策略下的命中率差异，用数据说话。

容量规划的最后一步是动态调整。缓存系统应该支持在线扩容、配置热更新，让容量能跟随业务增长灵活伸缩。定期用监控数据校准“热数据占比”这个核心指标，确保缓存池始终服务于真实的访问热点。

AI 应用场景

Python 演示

import randomimport time class PreheatedCache:    def __init__(self, hot_keys=None):        # 缓存字典，key -> (value, expire_time)        self.cache_map = {}        # 提前预热的 key 集合        self.hot_keys = set(hot_keys or [])        # 命中次数与未命中次数统计        self.hit_count = 0        self.miss_count = 0     def preload(self, key, value, ttl=300):        # 模拟离线批处理预热：直接写入缓存        self.cache_map[key] = (value, time.time() + ttl)        print(f"[preload] 预热 {key}")     def get_or_compute(self, key, compute_func, ttl=300):        # 按需触发模式：先查缓存，未命中则计算        now = time.time()        if key in self.cache_map:            value, expire = self.cache_map[key]            if expire > now:                self.hit_count += 1                return value            else:                del self.cache_map[key]        self.miss_count += 1        value = compute_func(key)        self.cache_map[key] = (value, now + ttl)        print(f"[compute] 为 {key} 执行实时计算")        return value     def update(self, key, new_value, ttl=300):        # 增量预计算：只更新某个 key        if key in self.cache_map:            self.cache_map[key] = (new_value, time.time() + ttl)            print(f"[update] 增量更新 {key}")     def hit_rate(self):        total = self.hit_count + self.miss_count        if total == 0:            return 0.0        return self.hit_count / total  def fake_query(key):    # 模拟昂贵计算：sleep 50ms    time.sleep(0.05)    return f"data_{key}_{random.randint(1000, 9999)}"  if __name__ == "__main__":    cache = PreheatedCache(hot_keys=["user_1", "user_2", "user_3"])    for k in cache.hot_keys:        cache.preload(k, f"precomputed_{k}")     # 模拟 10 次请求：前 3 个 key 走缓存，后 2 个 key 用按需触发    for i in range(1, 6):        key = f"user_{i}"        result = cache.get_or_compute(key, fake_query)        print(f"请求 {key} -> {result}")     # 模拟增量更新    cache.update("user_1", "updated_data")     print(f"缓存命中率: {cache.hit_rate():.2%}")

1. self.hot_keys = set(hot_keys or [])用集合记录需要预热的 key，避免重复预热。
2. cache.preload(k, f"precomputed_{k}")模拟在流量到达前预先把热门 key 写入缓存。
3. self.cache_map[key] = (value, time.time() + ttl)缓存每个条目都带过期时间，过期后自动失效。
4. get_or_compute` 里 `expire > now判断缓存是否过期，未过期才命中。
5. self.hit_count += 1` 与 `self.miss_count += 1分别记录命中与未命中次数，用于计算命中率。
6. cache.update("user_1", "updated_data")演示增量预计算：只更新受影响的 key，不做全量重算。
7. fake_query` 中的 `time.sleep(0.05)模拟昂贵计算，通过对比缓存命中和实时计算的耗时差异理解预热价值。

常见误区

面试题