Redis缓存预热不充分？自动化脚本解决瞬间击穿

说到Redis缓存预热不充分，很多人第一反应是"没做预热"，但实际情况往往更隐蔽：预热脚本跑了，数据也写进去了，可上线后两三分钟内，缓存还是被打穿。根本原因在于——预热的数据根本没覆盖到真实的访问热点。要么是热点列表来自上周的离线统计，要么脚本没跑完就匆忙上线，要么热点已经更新但预热没跟着刷新。总之，缓存击穿的爆发窗口就在上线后的前几分钟，一旦扛不住，数据库直接裸奔。

明确一点：预热不充分 ≠ 没执行预热，而是预热数据没覆盖真实热点、没跑完、或没及时更新——这类缓存击穿问题在上线后 2–5 分钟内就会触发。

预热脚本必须覆盖「实时访问热力」而非「静态配置列表」

很多团队习惯把预热写成读取一个 hot_keys.txt 文件，然后逐条 SET。但这个文件往往来自上周的离线统计，完全无法反映新上架商品、突发热搜、运营活动这些实时热点。结果就是：用户一涌进来，product:102456 这种刚爆火的 key 根本不在预热列表里，直接穿透到后端，引发缓存击穿。

• 预热数据源优先级：线上采样（比如 Redis 的 INFO keyspace_hits/keyspace_misses 加上客户端埋点的 QPS） > 日志聚合（Nginx/应用日志） > 离线报表
• 脚本启动时应当自动拉取最近 2 分钟内高 QPS 但未命中的 key（例如命中率低于 0.5 且 QPS > 300），并立即加载
• 避免硬编码 key 列表；改用动态查询：redis-cli --scan --pattern "product:*" | xargs -n 100 redis-cli MGET，再配合业务层判断是否为有效热点

预热过程必须带「分批+超时控制」，否则卡死在慢查询上

全量预热最隐蔽的坑，是几个大 value 阻塞了整个流程。比如某个 banner:202605 的 key 里塞了 base64 图片，读取慢、写入也慢，导致后续 key 还没加载完，服务就已经对外暴露。这才是预热不充分最容易被忽视的原因，也是导致缓存击穿的关键隐患。

• 单次批量不超过 50 个 key，用 MGET + MSET 减少网络往返
• 每批设置 3 秒超时，超时则跳过该批，记录到 /var/log/redis-warmup-skipped.log，供后续人工介入
• 禁止在预热脚本中调用含事务、Lua 或 pipeline 的复杂逻辑；只做纯数据灌入
• 示例关键片段（Shell）：

  while IFS= read -r key; do  timeout 3 redis-cli GET "$key" 2>/dev/null |     grep -qE '^[{[]|^[a-zA-Z0-9+/]*={0,2}$' &&       redis-cli SETEX "$key" 3600 "$(redis-cli GET "$key")"done < <(redis-cli --scan --pattern "product:*" | head -n 50)

预热完成≠万事大吉，必须校验「缓存命中新鲜度」

脚本执行成功日志只说明命令发出去了，不代表数据真的进了缓存，或者没被 LRU 立刻淘汰。常见情况是：预热用了 SET，但 Redis 配置了 allkeys-lru 且内存吃紧，刚写入就被踢出。这才是最让人头疼的"假成功"，也是预热不充分导致缓存击穿的另一层隐患。

• 预热结束后，立刻抽样检查 10 个 key 的 TTL：redis-cli TTL product:10086，如果多数返回 -1（永久）或 -2（不存在），说明失败了
• 对比预热前后 keyspace_hits 和 keyspace_misses 的差值，增量比应该 ≥ 90%（也就是 100 次请求里至少 90 次命中）
• 在应用启动后 30 秒内，强制触发一次对预热 key 的模拟访问（比如调用 curl -X GET /api/cache-checkk=product:10086），验证整个链路是否通畅

真正难的是让预热脚本感知业务节奏：秒杀开始前 2 分钟自动加推库存类 key，榜单更新后 10 秒内刷新 top10——这些没法靠 cron 固定时间解决。得把预热能力做成可被事件驱动的轻量服务，而不是一个孤零零的 shell 脚本。这样才能从根本上解决Redis缓存预热不充分导致的缓存击穿问题。