为什么要主动演练缓存故障
缓存通常承担削峰和降低数据库压力的职责，但它也会把系统的稳定性假设集中到少数关键节点上。当大量键在相近时间过期、缓存集群抖动，或者回源链路突然变慢时，请求会在很短时间内穿透到数据库与下游服务。真正危险的并不是某个组件变慢，而是压力沿调用链同步放大。
因此，缓存雪崩演练的目标不应该只是证明“熔断器能够打开”，而是验证业务在资源受限时能否保持最小可用能力，并且在故障解除后平稳恢复。
演练前先定义可接受的损失
在注入故障之前，团队需要明确核心接口、非核心功能和数据一致性边界。核心查询可以返回短时旧数据，但订单确认等关键写操作不能伪造成功；推荐、排行等附加能力可以暂时关闭；异步任务可以积压，但必须限制队列长度。
建议先写下三组指标：用户侧成功率和延迟、服务侧线程池与连接池占用、数据侧回源请求量。只有把这些指标放在同一条时间线上，才能判断降级是在保护系统，还是把故障悄悄转移到了别处。
第一层保护：打散过期与请求合并
对批量写入的缓存键增加随机过期抖动，可以避免同一时刻集中失效。对于热点键，单纯延长有效期并不足够，还需要在应用层合并并发回源请求，让同一个键只有一个请求访问数据源，其余请求等待结果或读取可接受的旧值。
请求合并必须设置独立超时，不能让等待者无限堆积。若数据源已经超过预算，应尽快返回降级结果，而不是继续占用业务线程。
第二层保护：限流、熔断与降级协同
限流负责控制进入系统的总量，熔断负责阻止持续失败的下游调用，降级负责给用户一个可解释的结果。三者的触发顺序要通过演练验证。过早熔断会损失本可成功的请求，过晚熔断则可能耗尽连接池。
实践中可以为核心与非核心流量设置不同预算：核心链路保留固定资源，非核心链路在延迟升高时先收缩；熔断恢复采用少量探测流量逐步放开，避免缓存刚恢复就再次被回源洪峰击穿。
恢复阶段比故障阶段更容易被忽略
缓存节点恢复并不代表系统立即健康。积压任务、失败重试和用户刷新会形成第二波流量。恢复过程应限制回补并发，按业务优先级分批预热热点数据，同时观察数据库连接、慢查询与消息队列积压。
如果演练只记录“故障解除时间”，却没有记录“指标恢复到稳定区间的时间”，就无法评估恢复策略是否有效。建议把恢复时间目标单独列入验收标准。
一份可复用的检查清单
故障注入是否限定在可回滚的环境和时间窗口内。
热点键是否具备随机过期、请求合并与旧值兜底。
核心链路是否拥有独立的超时、并发和重试预算。
降级响应是否可识别，是否避免被误记为正常成功。
恢复后是否采用分批预热，并监控回源峰值。
告警、日志和链路追踪能否还原完整时间线。
一次有价值的演练，最终产物不是一张“通过”截图，而是明确哪些假设成立、哪些保护仍有缺口，以及下一次演练要收紧什么指标。只有把降级策略当作持续验证的工程能力，系统才能在真实流量和复杂依赖中保持韧性。
