不能全量重载，因为会压垮数据库和Redis并引发二次雪崩；应按业务优先级分批加载，只预热不可降级、无fallback、高并发必查的key，并确保结构一致、TTL随机、主从同步完成后再放量。
缓存雪崩后，为什么不能全量重载？
雪崩发生时，Redis里大量 key 同时失效或服务刚恢复，如果一上来就执行全量数据加载（比如从 MySQL 读全部商品、用户、订单表再塞进 Redis），会立刻引发两个问题：一是数据库瞬间被压垮，二是 Redis 自身写入吞吐打满，主从同步延迟飙升，甚至触发 OOM 或 maxmemory 驱逐。这不是“预热”，是“二次雪崩”。
按业务优先级分批加载的关键判断点
真正决定加载顺序的不是数据量大小，而是「哪些请求最先打进来、且失败后影响最大」。例如电商大促场景：
-
sku_info和cart:uid:这类 key 必须第一批加载——用户加购、下单路径直接中断 -
user_profile可第二批——登录成功后才查，有兜底逻辑（如返回默认头像） -
activity_rule若已过期，可第三批或跳过——活动结束就不需要了 - 日志类、埋点类、统计类 key 建议不预热——它们本就不该进主缓存层
核心原则：只预热「当前业务链路中不可降级、无 fallback、高并发必查」的 key。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
如何在代码里实现分批 + 优先级控制？
别用单个脚本硬编码所有表。推荐用配置驱动 + 异步队列方式：
- 定义优先级配置文件（如
cache-warmup-priority.yaml），每条含keyPattern、dataSource、batchSize、priority - 启动时按
priority升序拉取数据，但每批加载完必须检查redis.info("stats").get("used_memory_human")和redis.info("replication").get("master_last_io_seconds_ago")，超阈值则暂停 - 对高优 key 使用
pipeline批量写入，禁用SET单条；低优 key 可走异步线程池 + 限速（如每秒 ≤500 条） - 避免用
SCAN全量扫 DB 表——改用业务方提供的hot_sku_ids、recent_login_uids等轻量集合
容易被忽略的兼容性细节
分批预热不是“分批塞数据”就完事。以下三点常被跳过，却直接导致预热无效：
- 新旧 key 的
value结构必须一致——比如预热用的是 JSON 字符串，而线上代码期望的是HASH结构，加载后照样nil - 过期时间不能统一设成固定值，否则下一轮又雪崩。必须调用类似
setWithRandomExpiry()方法，基础 TTL 加 ±10% 随机偏移 - 主从同步完成前，不能开放读流量。需监听
INFO replication中master_sync_in_progress:0和slave_repl_offset与master_repl_offset差值
最麻烦的永远不是“怎么加载”，而是“怎么确认这批数据真能被业务代码正确消费”。上线前务必用真实流量回放验证第一批次 key 的命中率和响应耗时。
