预热前必须确认Redis连接和Key模式是否可预测，因自动预热依赖可枚举的key命名规则（如product:{id}），若key为无规律UUID则无法生成；需用SCAN验证key格式、确保数据源支持ID/时间范围等枚举条件，并避免KEYS阻塞生产环境。
预热前必须确认 Redis 连接和 Key 模式是否可预测
自动预热的前提是：你要预热的数据不是随机生成的，而是能通过业务逻辑或配置提前算出来。比如商品详情页缓存通常以 product:{id} 为 key，订单缓存用 order:{uid}:{date}。如果 key 是 UUID 或加密哈希且无规律，脚本没法“猜”出该刷哪些 key，预热就无从谈起。
实操建议：
- 先在 Redis 中用
SCAN 0 MATCH product:* COUNT 100抽样验证 key 命名是否符合预期 - 检查对应数据源（如 MySQL）是否有主键/时间范围等可枚举字段，用于生成 key 列表
- 避免直接用
KEYS *——生产环境会阻塞 Redis，SCAN 更安全
用 redis-py 批量写入时别忽略 pipeline 和序列化
单条 set 往 Redis 写几千个 key，网络往返开销大、速度慢。必须用 pipeline 打包，但要注意：pipeline 不会自动序列化 Python 对象，如果你存的是 dict 或 datetime，得自己处理。
常见错误现象：redis.exceptions.DataError: Invalid input of type: 'dict'. Convert to a byte, string, int or float first.
立即学习“Python免费学习笔记（深入）”；
实操建议：
- 用
json.dumps(obj, ensure_ascii=False).encode('utf-8')序列化复杂结构 - 对简单字符串值，确保传入的是
bytes或str，别传None或float('nan') - 每批 pipeline 控制在 100–500 条，太大可能触发 Redis 的 client-output-buffer-limit 限制
预热脚本要能区分“冷启动”和“增量更新”场景
上线新服务首次部署是冷启动，需要全量预热；日常可能是只刷新当天新增商品或失效缓存，属于增量。硬编码成“每次全刷”会导致重复写入、浪费资源，甚至覆盖了刚被业务逻辑更新的 hot data。
使用场景差异：
- 冷启动：读取数据库全量 ID 列表 → 生成全部 key → pipeline set
- 增量更新：查
WHERE updated_at > '2024-06-01 00:00:00'→ 只刷这部分 key - 加个命令行参数如
--mode=full或--mode=delta --since=2024-06-01显式控制
性能影响：全量预热建议放在低峰期执行，增量可定时每小时跑一次，避免与业务高峰争抢 Redis 带宽。
务必设置合理的 TTL 并验证是否生效
很多人写了 r.set(key, value) 就以为完事，结果缓存永不过期，后续改逻辑也没法自动淘汰旧数据。Redis 预热不设 TTL，等于埋了个内存泄漏隐患。
参数差异：
-
r.set(key, value, ex=3600)：设置 1 小时过期（推荐） -
r.setex(key, 3600, value)：效果相同，但不如上一种直观 - 别用
expire单独调用——pipeline 里不能混用命令类型，否则报错ResponseError: Command # 2 (EXPIRE) of pipeline is not supported
验证方式：预热后立刻执行 ttl product:123，确认返回值是正整数而非 -1（永不过期）或 -2（key 不存在）。
容易被忽略的地方：不同业务实体的缓存生命周期可能不同，商品详情缓存 1 小时，用户权限缓存可能要 24 小时——脚本得支持 per-key TTL 配置，而不是全局一个值。
