这个坑值得记一笔。五千条 prompt 缓存统一 TTL 一小时，整点批量写入，之后每小时整点全部失效，那一分钟 QPS 冲到三倍，接口开始 429。
刚开始盯着「失效后同时回源没有排队」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。TTL 固定且写入时间集中；过期时间没有随机抖动；缓存预热不分批。
动手时先看缓存条数与过期分布
redis-cli --scan --pattern 'llm:*' | wc -lTTL 加零到三百秒随机抖动
python -c "import random;print(3600+random.randint(0,300))"预热分桶 每批间隔两分钟
python warm.py --batches 20 --interval 120热点 key 单独设长 TTL
python hotkey.py --top 50 --ttl 21600我习惯把每一步的执行时间和结果记在一边，后面复盘省事。
改之前我把相关日志按时间截了一段存着，事后对时间线用得上。
怎么算真的好了，看的是同一批现象。整点 QPS 峰值降到原来的一点二倍以内，429 不再出现，命中率基本不变。
这里还有个坑。批量写入加固定 TTL 等于给自己安排定时雪崩，抖动是最低成本的对策。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。