缓存问题很少突然发生。真正的雪崩之前，通常已经出现了 TTL 集中、热点键过热、穿透请求增多、回源数据库压力升高等信号。提前看见这些信号，比事后扩容更有价值。
信号一：TTL 大面积集中
如果大量缓存使用同一个固定过期时间，又在同一批任务中写入，过期时间就会集中到一个窗口。窗口一到，请求同时回源，数据库和下游服务会被打满。
解决方式很简单：基础 TTL 加随机抖动，批量预热分段执行，核心缓存可以提前刷新。对于首页、榜单、配置类数据，还可以考虑逻辑过期和异步重建。
信号二：热点键承载过多流量
热点键不是坏事，坏的是没有识别和保护。秒杀、热门文章、活动配置、全局字典都可能形成热点。单个 key 流量过大时，Redis 本身、网络带宽和应用反序列化都会成为瓶颈。
可以通过本地短缓存、分片 key、读写分离、限流和降级策略缓解。关键是先监控到热点，而不是等到连接池耗尽才发现。
信号三：没有降级预案
缓存不可用时，系统应该知道哪些接口可以返回旧数据，哪些接口必须失败，哪些任务可以暂停。没有降级预案的缓存，就是数据库前面的一层单点心理安慰。
降级要提前写进代码和配置。比如读取失败时返回上一次快照，写入失败时记录补偿任务，非核心推荐内容直接隐藏。
复盘要看完整链路
缓存事故复盘不要只写“Redis 故障”。要看 key 设计、TTL 分布、回源 SQL、连接池、限流、告警和发布变更。只有把链路串起来，才能知道下一次该在哪里加护栏。
Redis 的价值是降低系统压力，不是把风险藏起来。看到 TTL、热点键和降级这三个信号，就能在雪崩之前先做处理。
正文完
