预热不充分指预热数据未覆盖真实热点、未执行完或未及时更新，导致上线后2–5分钟内缓存击穿；须用线上采样等动态数据源、分批超时控制、命中率校验及事件驱动机制。
预热不充分 ≠ 没执行预热，而是预热数据没覆盖真实热点、没跑完、或没及时更新 —— 这类问题在上线后 2–5 分钟内就会触发缓存击穿。
预热脚本必须覆盖「实时访问热力」而非「静态配置列表」
很多团队把预热写成读取一个 hot_keys.txt 文件然后逐条 SET，但这个文件往往来自上周的离线统计，无法反映新上架商品、突发热搜、运营活动等实时热点。结果就是：用户一涌进来，product:102456 这种刚爆火的 key 根本不在预热列表里，直接穿透。
- 预热数据源优先级：线上采样（如 Redis
INFO keyspace_hits/keyspace_misses+ 客户端埋点 QPS） > 日志聚合（Nginx/应用日志） > 离线报表 - 脚本启动时应自动拉取最近 2 分钟的高 QPS 未命中 key（例如命中率 300），并立即加载
- 避免硬编码 key 列表；改用动态查询：
redis-cli --scan --pattern "product:*" | xargs -n 100 redis-cli MGET配合业务层判断是否为有效热点
预热过程必须带「分批+超时控制」，否则卡死在慢查询上
全量预热常因某几个大 value（如含 base64 图片的 banner:202605）阻塞整个流程，导致后续 key 没加载完，服务就已对外暴露 —— 这是预热不充分最隐蔽的原因。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 单次批量不超过 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-check?k=product:10086），验证链路通路
真正难的是让预热脚本感知业务节奏：秒杀开始前 2 分钟自动加推库存类 key，榜单更新后 10 秒内刷新 top10，这些没法靠 cron 固定时间解决 —— 得把预热能力做成可被事件驱动的轻量服务，而不是一个孤零零的 shell 脚本。
