预热前必须确认Redis连接和Key命名规范，否则脚本八成失败；需确保ping通、key与线上完全一致、Cluster下key同slot，批量用pipeline（transaction=False）、分批控制数量与节奏，并校验数据源完整性、内存使用及加锁防重。
预热前必须确认 Redis 连接和 Key 命名规范
脚本跑不起来，八成卡在连不上或写错 key。别急着写逻辑，先确保：
• 用 redis.Redis(host='xxx', port=6379, db=0) 能成功 ping() 通，超时建议显式加 socket_connect_timeout=2；
• 所有预热 key 必须和线上应用实际读取的完全一致——比如应用拼的是 f"product:{id}:detail"，脚本就不能写成 product_detail_{id}；
• 如果用了 Redis Cluster，得用 redis.RedisCluster，且所有 key 必须落在同一 slot（否则 MSET 会报 ClusterCrossSlotError）。
批量写入优先用 pipeline，别单条 set
1000 条数据逐条 set 可能要 3 秒，用 pipeline 通常压到 200ms 内。关键点：
• pipe = redis_client.pipeline(transaction=False) —— transaction=False 关掉事务能提速；
• 批量塞值用 pipe.set(key, value)，最后统一 pipe.execute()；
• 单次 pipeline 不宜超过 5000 条，太大可能触发 Redis 的 client-output-buffer-limit；
• 若值是 JSON 字符串，直接存 json.dumps(obj)，别在脚本里反复 json.loads 再转回字符串。
预热数据源选 CSV 还是数据库？看更新频率
数据源决定脚本健壮性：
• 静态配置类（如城市列表、状态码映射）：用 CSV 文件最稳，脚本启动时 pandas.read_csv('config.csv') 读一次就行；
• 动态业务数据（如热门商品详情）：必须查数据库，但别在预热脚本里写 SQL 连接池——直接调用公司已有的 DAO 方法，复用连接和重试逻辑；
• 绝对避免从线上 API 拉数据，网络抖动会导致预热中断，且无法控制并发量；
• 所有数据源读取后，务必校验字段完整性，比如 if not row.get('id') or not row.get('name') 就跳过，防止写入空 key。
如何避免预热时打爆 Redis 内存？
缓存雪崩不是吓唬人，真实踩过坑：
• 用 redis_client.info('memory')['used_memory_human'] 在预热前查当前内存，如果已超 80%，直接退出并告警；
• 对大 Value（如 >10KB 的 HTML 片段），改用 setex 并设较短 timeout（比如 3600），别一股脑全设永不过期；
• 分批执行：每写入 500 条就 time.sleep(0.1)，给 Redis 缓冲时间，尤其在低配云 Redis 上这步不能省；
• 预热脚本本身加锁，用 redis_client.set('cache_warmup_lock', '1', nx=True, ex=300)，防止定时任务重复触发。
立即学习“Python免费学习笔记（深入）”；
真正难的不是写几行 set，而是让预热行为和线上服务节奏对齐——比如新版本上线前 2 分钟才开始预热，且必须等 DB 数据同步完成后再启动。这些依赖项不显式编排，脚本再漂亮也没用。
