流量切换时缓存预热不充分，本质是新节点未加载真实、及时、完整的热点数据，导致请求穿透数据库；需用最近1–2分钟线上Redis指标（如keyspace_misses增速top100、QPS>50且命中率低的key）替代静态离线列表预热。

流量切换时缓存预热不充分，本质是新节点或新缓存实例在承接流量前，未加载真实、及时、完整的热点数据，导致刚切进来的请求大量穿透到数据库。这不是“没预热”，而是预热的数据不准、不全、不快——尤其在灰度发布、蓝绿部署、跨机房切流、CDN回源切换等场景下极易触发。

用线上实时采样替代静态列表

切流前预热若依赖离线统计（比如上周的 hot_keys.txt），根本无法覆盖新活动商品、突发热搜、临时运营入口等实时热点。必须改用动态数据源：

• 优先拉取最近 1–2 分钟的线上 Redis 指标：如 keyspace_misses 增速 top100、客户端埋点中 QPS > 50 且命中率 的 key
• 配合 Nginx 日志或 APISIX 访问日志，提取高频 path → 映射为缓存 key（如 /product/102456 → product:102456）
• 禁止硬编码 key 列表；改用 redis-cli --scan --pattern "product:*" 扫描后结合业务逻辑过滤有效热点

分批加载 + 超时熔断，防止卡死阻塞上线

全量扫描+加载容易因个别大 value（如 banner:202605 含 base64 图片）或慢查询拖垮整个预热流程，造成“只预热了前 30% key，流量已切过来了”。

• 单次批量严格控制在 ≤ 50 个 key，用 MGET + MSET 减少网络往返
• 每批设置 3 秒超时，超时立即跳过，记录到 /var/log/redis-warmup-skipped.log
• 预热脚本本身不执行事务、Lua 或 pipeline，只做纯数据灌入，避免引入额外延迟和失败风险

切流后校验命中新鲜度，而非只看脚本是否跑完

脚本输出 “Success” 不代表缓存真可用。刚写入的 key 可能被 LRU 立即淘汰，或因内存不足被驱逐，或 key 过期时间设得太短。

• 切流后 30 秒内，主动抽检 10–20 个刚预热的 key：检查是否存在、TTL 是否合理（建议 ≥ 3600）、value 是否完整
• 监控指标联动：观察 Redis 命中率是否在 1 分钟内回升至 90%+、DB QPS 是否未出现尖峰
• 对关键路径（如商品详情、用户首页）加轻量级兜底：若预热 key 未命中，启用本地缓存 fallback 或降级返回简化数据

结合事件驱动补漏，应对突发热点

预热再快也有窗口期。需在切流后持续感知真实流量，自动补热：

• 监听 MQ 中的商品上架、活动开启事件，触发对应 key 的即时预热
• 在网关层对 miss 率突增的 path 自动上报并触发增量预热任务（例如 10 秒内 product/* miss 超 200 次）
• 对高危 key（如 user:1000001）设置逻辑过期，避免物理过期瞬间击穿