Redis雪崩后缓存预热顺序：按业务优先级分批加载

在缓存雪崩发生后，最令人担忧的不仅仅是Redis数据清空，而是服务刚恢复就急于将所有数据一次性填回。这种做法极易导致数据库连接池瞬间崩溃，Redis自身也会因写入量过大而引发主从同步延迟飙升，甚至触发内存驱逐机制。这并非真正的“预热”，而是在制造二次雪崩。

缓存雪崩后，为什么不能全量重载？

设想这样一个场景：大量Key同时过期，或者Redis刚刚经历重启。此时若一股脑将MySQL中所有商品、用户、订单数据全塞进Redis，后果将非常直接——数据库连接池瞬间爆炸，Redis自身写入吞吐被拉满，主从复制陷入停滞，甚至触发OOM或maxmemory驱逐策略。原本想修复问题，结果却雪上加霜。

按业务优先级分批加载的关键判断点

真正决定加载顺序的，从来不是哪个数据量最大，而是哪个请求最先到达、哪个请求失败后影响最严重。以电商大促场景为例：

• sku_info 和 cart:uid: 这类Key必须第一批加载——用户加购、下单路径一旦中断，业务立刻瘫痪
• user_profile 可以第二批加载——登录后才调用，且通常有兜底逻辑，比如返回默认头像
• activity_rule 若已过期，第三批甚至跳过都行——活动结束后没必要再缓存
• 日志类、埋点类、统计类Key建议不预热——它们本就不该占用主缓存层资源

核心原则只有一条：只预热那些在当前业务链路中不可降级、没有fallback、高并发场景下必须查询的Key。

如何在代码里实现分批 + 优先级控制？

不要用一个巨大的脚本硬编码所有表的加载逻辑。更优的方案是采用配置驱动加异步队列：

• 定义优先级配置文件（例如 cache-warmup-priority.yaml），每条记录包含 keyPattern、dataSource、batchSize、priority
• 启动时按优先级升序拉取数据，但每批加载完成后必须检查两个指标：redis.info("stats") 中的 used_memory_human 和 redis.info("replication") 中的 master_last_io_seconds_ago，超过阈值则暂停
• 高优先级的Key用 pipeline 批量写入，避免单条 SET；低优的Key走异步线程池并加上限速，例如每秒不超过500条
• 不要用 SCAN 全量扫描数据库——而应让业务方提供 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的命中率和响应耗时。