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的命中率和响应耗时。