预热脚本失效主因是过期时间未加随机偏移导致集体过期；需为每个key设置1800–3600秒基础过期时间并叠加±300–600秒随机值，避免整点雪崩。

预热脚本跑完就失效？过期时间没加随机偏移是主因

预热后刚上线就雪崩，大概率不是没预热，而是所有 setex 设置的过期时间完全一致。比如统一设成 3600 秒，一小时整点集体过期，数据库瞬间被压垮。

必须给每个 key 加上随机偏移量，把失效时间打散：

• 基础过期时间建议设为 30–60 分钟（1800–3600），别贪长
• 随机范围至少取 ±5–10 分钟（300–600），避免集中在某几分钟内
• 别用 time.time() + base 这种写法——它不解决批量 key 同时过期问题；重点是每个 key 的 expire 值要独立生成

import random<br>pipe.setex(key, 3600 + random.randint(0, 600), json.dumps(value))

用 pipeline 预热却卡住或报错？检查 Redis 连接与 DB 选择

预热脚本在本地跑通，部署到生产就超时或连不上，90% 是连接配置没对齐：

• redis.Redis(host='localhost', port=6379, db=0) 在容器或云环境里基本等于写死失败——localhost 指的是容器自己，不是宿主机或 Redis 实例
• 确认实际 Redis 地址、端口、密码（password 参数）、DB 编号是否和线上配置一致，尤其注意 db=0 是否被其他服务占用
• 如果用了哨兵或集群，redis.Redis 不支持，得换 redis.sentinel.Sentinel 或 redis.cluster.RedisCluster

预热数据明明进了 Redis，但请求还是打到 DB？缓存键名不一致是隐形杀手

预热脚本里用 "homepage_banner"，而业务代码拼的是 f"banner:{env}:v2"，结果就是“预了等于没预”。这种错不会报错，只会静默失效。

• 把预热脚本里的 key 定义抽成常量模块（如 cache_keys.py），业务代码和预热脚本共用同一份
• 上线前用 redis-cli --scan --pattern "banner*" 手动扫一遍，确认 key 真的存在且格式匹配
• 避免在预热时用 json.dumps 但业务层用 pickle 解析，序列化方式必须严格一致

系统启动即预热，但 DB 尚未就绪导致失败？加重试和健康检查

微服务启动顺序不可控：应用进程起来了，Redis 连上了，但 MySQL 还在初始化连接池，这时预热调用 get_top_products() 直接抛异常，整个预热中断，缓存空空如也。

• 预热函数内部对每个数据源调用加 try/except，单个失败不影响其他 key 加载
• 关键依赖（如 DB）启动后主动发一次健康探测（如 SELECT 1），成功后再触发预热主逻辑
• 不要把预热塞进 __init__.py 或 Django 的 ready() —— 它们没超时控制；单独起一个带 timeout 的同步任务更稳妥

预热不是“跑一遍脚本就完事”，它是连接配置、键名规范、过期策略、依赖时序四个环节咬合的链条，漏掉任意一环，开局雪崩只是时间问题。