redis-cli --pipe < warmup.txt # warmup.txt 每行一条 SET key value EX 3600 INFO stats
每次发版后十分钟，首页接口 TP99 从 180 毫秒涨到 2200 毫秒，数据库 CPU 顶到 90%。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，实例重启时进程内缓存清空，远端缓存又设了较短 TTL，流量一进来全部回源，热点数据在短时间内被反复重建。
围绕「缓存预热方案」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
处理上按这个顺序：发布前按访问日志把热点键重放一遍 写回远端缓存；预热脚本限速执行 别转手把数据库再打一遍；进程内缓存启动后异步加载 不等第一个请求。
改完只确认一件事：发版后立刻观察，TP99 不超过平峰的 1.3 倍，库 CPU 没有尖刺。