缓存服务一重启，数据库 CPU 瞬间 100%。你不是第一个遇到这个问题的人。

这个问题有个专有名词叫"冷启动穿透"——严格来说它和标准的缓存雪崩（大量 key 同时过期或节点宕机）不是一回事，但后果类似：缓存里没有数据，所有请求穿透到数据库。很多人第一反应是"缓存挂了"，其实真正的原因是缓存冷着的时候，你的策略没选对。

选择缓存策略本质上是一道选择题：你的业务能不能接受缓存冷启动时的那几秒"冷"？如果能，最省事的策略就够了；如果不能，你需要付出什么代价来预热。

本文是一篇决策导向的文章，不是操作教程。不教你怎么配 Redis，也不讲缓存穿透/击穿——只聚焦冷启动场景下三种策略的选择问题。

一、先看矩阵：你的系统在哪个象限？

选策略之前，先看两个变量。

第一个是缓存缺失容忍度：你的业务能不能接受缓存冷启动时的"缓存穿透"？

• 高容忍：CMS、后台管理、数据分析平台
• 低容忍：秒杀、实时推荐、高并发 API

第二个是数据预热成本：预热需要多少时间和资源？

• 低成本：热点数据 < 10,000 条，预热耗时 < 10ms
• 高成本：热点数据 > 100,000 条，预热耗时 > 100ms 或需要大量计算

两个变量组合起来，就是四个象限：

下面逐个拆解每个象限。你可以在读的过程中不断回看这个矩阵，找到自己业务的位置。

二、高容忍 × 低成本：惰性加载 + 保护

大多数团队第一次遇到冷启动穿透时的反应是：加预热。但有时候你不需要预热——你需要的只是一个保护方案。

惰性加载的策略很简单：不预加载任何数据，请求到了才查缓存，缓存没有就去数据库查，查到了再写回缓存。零启动成本，系统重启后立刻可用。代价是第一次请求慢，并发够大时数据库可能被打穿。

但惰性加载最容易被忽视的问题不是"慢"，是雪崩效应。假设你的服务有 50 个实例同时重启，每个实例的缓存都是空的。这时候哪怕只有一个请求打到每个实例上，数据库就要承受 50 倍的瞬时压力。如果用户的请求再密集一些——比如所有实例同时收到 100 个请求——数据库瞬间就面临 5000 个并发查询。

50 倍的放大效应——这就是雪崩。

保护怎么做？

“保护"就是在惰性加载的基础上加一个断路器或限流器：当数据库连接数超过某个阈值时，拒绝后续请求，或者返回降级响应。

常见的保护手段有三种：

1. 连接池限流：设置数据库连接池上限，超过上限的请求排队或超时。简单有效，但排队可能导致请求堆积。
2. 断路器：当数据库错误率达到阈值（比如常见默认值 50%，Hystrix 标准，请根据业务调整），断路器打开，直接返回降级响应，不再请求数据库。这能保护数据库不被完全打垮。
3. 缓存空值：当数据库查询为空时，也把"空结果"缓存起来（设置较短 TTL），避免同一 Key 的反复穿透。

这其实是一个权衡：你是接受少量请求的慢响应，还是接受系统启动的额外延迟？

实测数据

我跑了一组模拟实验，配置如下：10,000 个缓存键，20% 是热点键（占 80% 访问量），50 个并发 worker，总共 10,000 次请求。运行环境：Go 1.26.4，本地单机 Redis，单表简单查询。

结果：

惰性加载+保护的命中率只有 62%，DB 峰值连接数冲到 50（模拟的断路器上限），平均延迟接近 3.7ms——比预热方案慢了将近一倍。

但注意：这个数据是在高并发、热点集中的场景下测的。如果你的系统 QPS 很低，惰性加载的表现完全不同——命中率会更高，DB 连接数也不会成为瓶颈。

什么时候选这个象限？

• QPS 低：系统日常 QPS < 100，数据库扛得住偶尔的全量穿透
• 容忍度高：首次访问的几秒延迟对业务无影响（如 CMS、后台管理）
• 数据量大：全量预热成本太高，且大部分数据可能永远不会被访问
• 快速迭代：服务频繁重启/发布，没有时间等预热完成

如果你在做一个内部管理系统，用户每天就几十个人用，缓存预热完全是浪费感情。惰性加载 + 一个简单的限流就够用了。

三、低容忍 × 低成本：主动预热

如果你的业务容忍度低——首次访问延迟不可接受，那就主动预热：系统启动时，先把热点数据加载到缓存里。

我的做法是：既然冷启动穿透是因为缓存冷，那就让缓存不冷。提前把预测会被频繁访问的数据加载进去，让系统在对外提供服务前就已经"暖"了。

关键问题：预热什么？

主动预热最核心的问题不是"怎么预热”，而是"预热什么"。加载了不该加载的数据，比不加载更糟糕——浪费内存、拖慢启动。

我一般把预热数据分为两类：

1. 可预测的热点：比如电商系统的商品详情、配置中心的配置项、用户的权限数据——这些几乎 100% 会被访问
2. 统计出来的热点：通过历史访问日志分析出来的高频 Key，比如过去 24 小时 PV Top 1000

第二类有一个陷阱：热点是会变的。昨天的高频 Key 今天可能就冷下来了。所以主动预热通常需要一个"预热 + 定期刷新"的组合方案。热点预测永远有误差。我常用的做法是：对预测的热点设置较短的 TTL，让缓存自己"验证"这个热点是否真的热——如果访问频率低，TTL 过期后自然淘汰。

怎么做定期刷新？两种思路：

• 定时全量刷新：每 N 分钟重新跑一次热点分析，重新加载热点数据。简单但浪费——热点数据可能没变。
• 增量监听：监听数据库的变更日志（如 MySQL 的 binlog，可以使用 Canal、Debezium 等成熟 CDC 工具），数据变了才更新缓存。成本高但精准。

大部分团队从定时全量刷新开始就够了——又不是所有数据每秒都在变。

还有一个容易被忽略的问题：预热的数据应该设置什么样的 TTL？

如果你预热的商品详情设置 24 小时 TTL，但商品价格在 2 小时后变了呢？用户看到的价格就是错的。我踩过这个坑之后的做法是：预热数据设置较短的 TTL（比如 5 分钟），同时配合定期刷新来续期。这其实是一个自动降级机制——刷新任务挂了后缓存自动过期，系统退回到惰性加载模式。虽然不是最优状态，但至少不会提供过期数据。

注意：所有预热数据的 TTL 不要设成相同的值。加上随机偏移（比如基础值 ± 随机范围），避免同时过期触发第二次雪崩。

启动时间的账

预热是要花时间的，而且这时间花在"系统启动阶段"——也就是你最希望系统快速上线的时候。

从我的基准测试来看：

大多数业务场景的热点数据在 1,000-10,000 条这个量级，预热的成本不到 3ms。从这个角度看，主动预热几乎是"免费的"。

但有一个例外：如果你的热点数据是百万级的，320ms 的预热时间在微服务架构中可能触发健康检查的超时。这个场景我会放到后面的"高成本"象限讨论。

怎么实现？

主动预热最常见的实现方式是：在应用启动后、对外提供服务前，执行一个预热函数。

func Warmup(ctx context.Context, redis *redis.Client) error {
    hotKeys, err := loadHotKeys(ctx)
    if err != nil {
        return fmt.Errorf("加载热点列表失败: %w", err)
    }
    
    // 批量写入 Redis
    pipe := redis.Pipeline()
    for _, item := range hotKeys {
        pipe.Set(ctx, item.Key, item.Value, item.TTL)
    }
    _, err = pipe.Exec(ctx)
    if err != nil {
        // 预热允许部分失败，但至少记录日志
        log.Printf("预热部分写入失败: %v", err)
    }
    return nil
}

这段代码在 Spring Boot 中通常放在 @PostConstruct 或 CommandLineRunner 里（注意：Spring Boot 3.x + Java 17+ 需要使用 jakarta.annotation 包），在 Go 中放在 main() 函数中服务启动之前。

注意：如果使用 go Warmup() 异步预热，服务启动时缓存可能尚未就绪。Spring Boot 的 @PostConstruct 默认同步阻塞。两种语言的预热语义不同，需要根据业务决定。

还有一个容易被忽略的问题：预热失败怎么办？ 如果数据库在预热时挂了，预热函数返回错误，你的服务应该拒绝启动，还是先启动再说？

我一般这样区分：对于秒杀系统，缓存没有预热好就上线等于灾难——应该阻止启动。对于一般业务，更合理的做法是：预热失败打印警告，服务继续启动，让惰性加载兜底。

多实例场景的陷阱

50 个实例同时重启，每个都执行一次预热——等于 50 次同样的数据库查询同时打过去。经典解法是使用分布式锁或 leader 选举，只让一个实例执行预热，预热结果共享给其他实例。

如果你的业务已经上了服务发现或配置中心，可以借助这些基础设施来做 leader 预热：启动时先尝试获取分布式锁，拿到锁的实例负责预热，其他实例等待预热完成或直接使用缓存中的现有数据。

什么时候选这个象限？

• 热点可预测：你知道哪些数据会被频繁访问（比如商品详情、配置项）
• 容忍度低：首次访问延迟不可接受（比如秒杀系统、实时推荐）
• 数据量适中：热点数据量 < 100,000 条，预热成本可控
• 服务重启不频繁：每次重启都做一次预热，启动频率越低越划算

四、高容忍 × 高成本：渐进式预热

主动预热的前提是你"知道"热点是什么。但如果热点不确定呢？

比如你做的是一个社交 Feed 系统，每个用户看到的内容都不一样。你没法提前知道"哪个用户的 Feed 会被访问最多"，因为热点完全取决于用户行为。

这时候主动预热没用——你不可能预热所有用户的 Feed。惰性加载+保护又太被动——用户量大，首次访问的延迟会拉低整体体验。

渐进式预热就是第三种选择：先让系统起来，然后边服务边预热。

这听起来像是"两全其美"，但它有一个隐含的代价：预热期间，部分请求仍然会穿透到数据库。渐进式预热不是在"要不要穿透"之间选，而是在"穿透多少"和"等待多久"之间找平衡点。

怎么做？

渐进式预热的做法是：系统启动后立即开始分批加载热点数据，同时用限流/断路器保护数据库。和主动预热的关键区别在于：服务不需要等预热完成再启动。

func GradualWarmup(ctx context.Context, redis *redis.Client) {
    // 使用游标分页加载，避免一次性加载全部热点到内存
    var cursor int64
    batchSize := 100
    
    for {
        hotKeys, nextCursor, err := loadHotKeysPage(ctx, cursor, batchSize)
        if err != nil {
            log.Printf("分批加载热点失败: %v", err)
            break
        }
        
        // 每批写入 Redis
        pipe := redis.Pipeline()
        for _, item := range hotKeys {
            pipe.Set(ctx, item.Key, item.Value, item.TTL)
        }
        _, err = pipe.Exec(ctx)
        if err != nil {
            log.Printf("预热部分写入失败: %v", err)
        }
        
        // 每批之间间隔 200ms，给数据库喘息空间
        time.Sleep(200 * time.Millisecond)
        
        if nextCursor == 0 {
            break
        }
        cursor = nextCursor
    }
}

关键参数是 batchSize 和批间隔。batchSize 太大等于全量预热，太小又预热太慢。我的建议是从 100 开始，根据预热期间数据库的负载动态调整。

从我的模拟实验来看，渐进式预热的表现和主动预热非常接近：命中率 82.1%，DB 峰值连接只有 1。

它和主动预热的核心差异不是性能，是灵活性：

• 主动预热：启动时一次加载完，之后就不管了
• 渐进式预热：持续加载，可以动态调整预热策略

比如，你可以根据预热期间的缓存命中率来动态调整：如果命中率已经超过 90%，可以放慢预热速度甚至停止；如果命中率仍然很低，加快预热速度。

和主动预热怎么选？

如果你的热点是明确的、稳定的，选主动预热就够了，不需要渐进式的复杂性。只有在你不确定或者数据量大到一次加载不完的时候，渐进式预热才值得。

我常用的判断标准：如果预热耗时超过服务启动时间的 20%，就该考虑渐进式预热了。

什么时候选这个象限？

• 热点不确定：你不知道哪些数据会被频繁访问
• 数据量大：全量预热会显著拖慢启动（百万级以上）
• 需要持续更新：热点数据会随时间变化，需要持续加载
• 高可用要求：不能因为预热而延迟服务启动

五、低容忍 × 高成本：最棘手的象限

如果你的业务既对延迟敏感（低容忍），又需要预热大量数据（高成本），矩阵的右下角——这是最难的场景。

矩阵上说"渐进式预热（或架构优化）"。我来展开"架构优化"是什么意思。

这个象限的核心矛盾是：系统启动必须快，但缓存又不能不预热。渐进式预热可以缓解这个问题——服务先起来，边服务边预热——但预热期间仍然会有部分请求穿透到数据库，低容忍度的业务可能接受不了。

这时候有两条路：

第一条路：本地缓存 + 预热拆分 在应用层加一层本地缓存（如 Go 的 sync.Map、Java 的 Caffeine），热点数据优先从本地缓存读取。预热只预热 Redis 这一层，本地缓存靠惰性加载。启动速度几乎不受影响，本地缓存命中率在预热完成后自然下降。代价是多了一层缓存一致性要维护。

第二条路：重新评估缓存必要性 有时候"低容忍 + 高成本"意味着你的架构选型有问题——缓存不是最好的解决方案。比如可以考虑：

• 数据分片：把一个大 Redis 拆成多个，每个分片的数据量变小，预热成本自然降低
• 读写分离：读走从库、写走主库，减少缓存的压力
• 换个思路：是否可以用 CDN 或预计算来代替缓存？

六、决策树：三步走到答案

如果上面四个象限看完还是不确定，走这个流程：

1. 你的业务能接受缓存冷启动吗？

   • 能 → 惰性加载+保护就够了（回到高容忍×低成本）
   • 不能 → 进入下一步

2. 你知道热点数据是什么吗？

   • 知道 → 主动预热（低容忍×低成本）
   • 不知道 → 进入下一步

3. 预热会拖慢启动吗？

   • 不会 → 主动预热（即使用统计出来的热点也值得）
   • 会 → 渐进式预热（高容忍×高成本 或 低容忍×高成本）

这个决策树覆盖了大多数场景。如果你走到第三层还是不确定，说明你的场景比较特殊——可能根本不需要缓存，或者需要重新考虑架构。

比如有些场景下缓存 Key 设计不合理，大部分请求都集中在少数 Key 上——这时候与其纠结预热策略，不如先看看缓存的设计是否合理。

矩阵之外：什么时候不该用缓存？

最后说一个反直觉的结论：有时候不做缓存，比做缓存好。

如果你的数据库本身响应就很快（比如单表百万级的 PostgreSQL，简单主键查询场景），缓存引入的复杂性可能得不偿失。缓存预热、缓存一致性、缓存穿透——这些问题的维护成本，可能超过缓存带来的性能收益。

我的判断标准：如果数据库 P99 延迟 < 5ms，且 QPS < 1000，先别急着加缓存（注意：这只是简单查询场景的参考值，复杂 JOIN 或高并发下 P99 远不止 5ms）。先看看慢查询能不能优化。缓存是用来解决"优化解决不了的问题"的，不是用来掩盖设计缺陷的。

还有一点：加了缓存不等于加了预热。很多团队上了 Redis 但没做预热，结果上线第一天缓存是空的，数据库被打穿。如果你决定用缓存，至少要确保惰性加载+保护这一层兜底是到位的。先让它不崩，再考虑怎么让它快。

我见过一个案例：一个日活百万的 App，缓存集群重启后数据库直接被冲垮，DBA 紧急扩容才恢复。事后排查发现，他们根本没有缓存缺失的保护机制——Redis 一重启，数据库就裸奔。加一个简单的限流，整个事故就能避免。

回到那个矩阵

没有银弹。选对策略比选对工具重要。

大多数团队遇到冷启动穿透的第一反应是"加预热"——这没错，但问一句"我的场景真的需要预热吗"往往更值钱。

回到开头的那个矩阵：你的业务在哪个象限？

• 高容忍 × 低成本 → 惰性加载+保护，省掉预热的运维成本
• 低容忍 × 低成本 → 主动预热，命中率最高
• 高容忍 × 高成本 → 渐进式预热，在灵活性和安全感之间找到平衡
• 低容忍 × 高成本 → 渐进式预热（或重新考虑架构）

你的业务对"冷"有多敏感？

下次遇到缓存重启后数据库 CPU 100% 的问题，先问自己三个问题：我的业务能忍多久？我知道热点在哪吗？预热会影响启动吗？问清楚了，方案自然就出来了。

原文发布于 止语Lab