S27-J02 · 缓存预热与分布式锁

适用读者：上线后"冷缓存打爆数据库"的人。
前置：S12-J01（击穿）、S12-J03（分布式锁）。
覆盖旧文：529(263) = 263 点。
扩展点：E-S27-012（预热的三种模式）。
上一篇：S27-J01 · 分布式可靠性四件套：业务 Key、Single-flight、僵尸 Owner、Stage
下一篇：S27-J03 · 验证码与风控。

1. 一句话结论

预热解决"冷启动瞬间打爆 DB"，锁解决"多个实例重复预热"。两者绑定，是因为预热本身就是一次"只该由一个人做的事"。

模式	做法	风险
启动预热	应用启动时拉热点	多实例重复拉
定时预热	低峰期定时刷	与业务高峰错开
懒加载 + 锁	首次访问时加载	首个用户慢

2. 预热的三种模式（E-S27-012）

模式	适合	注意
全量预热	热点数据小	启动慢
Top-N 预热	热点集中	需要热度数据
分片预热	数据大	分片并行 + 限速

判据："冷启动时 DB 能承受全量查询吗？" 不能 → 必须预热 + 限速。

3. 锁在预热中的三个作用

作用	说明
防重复	多实例只让一个拉
防击穿	与 S12-J01 的互斥重建同构
限速	锁粒度控制并发

"为什么不用"每个实例各拉一次""：N 个实例 × 全量数据 = N 倍压力——正好是预热想避免的。

4. 预热的失败处理

情况	处理
预热超时	部分预热 + 懒加载兜底
锁持有者崩溃	租约过期（J01 的 fencing）
数据变更	预热后仍要处理失效（S12-J02）

5. 五个误区

误区	真相
"每个实例都预热更保险"	会放大 DB 压力
"预热完就不用管失效"	仍需一致性方案
"预热越全越好"	启动慢、内存高
"锁只是为了互斥"	还用于限速
"预热失败就重启"	应先降级

6. 自检

三种预热模式？
为什么锁和预热绑定？
"每实例各拉一次"的问题？
预热失败怎么兜底？
预热后还要处理什么？

7. 下一篇

S27-J03 · 验证码与风控：滑块设计与实现

预热讲完，下一篇讲滑块验证码的真正难点。

本篇属于系列《S27 · 杂项归档与工具实测》。旧文来源：A-529；扩展点 E-S27-012。