Redis 缓存雪崩与穿透排查手册

引言：缓存本是为了给数据库减负，可一旦缓存本身出问题，数据库反而会在瞬间承受全部流量。本文把最常见的两种故障——缓存雪崩与缓存穿透——放在一起讲：先分清概念，再给出可操作的排查清单，最后给出防护配置，方便直接对照落地。

一、先分清：雪崩、穿透、击穿不是一回事

雪崩是大量缓存同时失效，或者 Redis 本身宕机，导致请求集中打到数据库，特征是突发、批量。穿透是请求的数据在缓存和数据库中都不存在，每次请求都绕过缓存打到数据库，特征是持续、可被恶意构造。击穿则是单个热点 Key 失效瞬间被大量并发打到数据库，特征是单点、高并发。排查的第一步，就是先判断属于哪一种，因为三者的解法完全不同。

二、成因分析

缓存雪崩的常见成因：第一，业务上线或批量写入时给大量 Key 设置了相同的过期时间，到点一起失效；第二，Redis 单点故障、主从切换失败或网络分区导致缓存整体不可用；第三，缓存预热不足，冷启动后数据库直接承压。缓存穿透的常见成因：第一，查询不存在的用户 ID、订单号等，被爬虫或恶意请求反复刷；第二，参数校验缺失，非法 ID 直接进入缓存查询链路；第三，缓存中没有对空结果做任何处理，导致同样的无效请求每次都回源。

三、排查步骤

第一步，看现象和时间点：雪崩往往与某个整点、批量过期或 Redis 故障时间点吻合；穿透则表现为某些 Key 的命中率持续走低、数据库慢查询中出现大量不存在的查询。第二步，看监控指标：Redis 的命中率、QPS、内存与连接数，数据库的 QPS、慢查询与连接数，以及应用侧的缓存访问日志。第三步，定位 Key：用 MONITOR 或慢日志抽查高频 Key，统计 Top Key 的访问量与命中情况，确认是批量失效、热点失效还是不存在的 Key 被反复请求。第四步，复现与验证：对可疑 Key 做小流量灰度验证，观察加了防护后数据库 QPS 是否回落，避免凭猜测直接全量改配置。第五步，复盘：记录失效时间、影响范围与恢复手段，把过期时间、空值策略写进上线检查清单。

四、防护手段

针对雪崩：过期时间加随机抖动，避免集中失效；核心热点 Key 采用逻辑过期加后台异步刷新；本地缓存加 Redis 多级缓存兜底；部署主从加哨兵或 Cluster 保证高可用；数据库侧做好熔断与降级，必要时返回默认值而不是拖垮服务。针对穿透：对数据库查不到的结果缓存空值并设置较短过期时间；请求前用布隆过滤器拦截明显不存在的 Key；入口层做参数校验，非法 ID 直接拒绝；对异常高频请求做限流与黑名单。针对击穿：对热点 Key 加互斥锁，只放一个请求回源，其余请求等待或返回旧值。

五、示例配置

Redis 方面，建议把淘汰策略设为 allkeys-lru，并根据内存合理设置 maxmemory，避免内存打满后写入失败。示例：maxmemory 2gb，maxmemory-policy allkeys-lru。过期时间不要写死，例如基础过期 3600 秒，再加 0 到 300 秒的随机值。空值缓存示例：数据库查不到时写入一个特殊空值标记，过期时间设为 60 秒，下次同样请求直接命中空值，不再回源。布隆过滤器示例：系统启动时把已有 ID 集合写入过滤器，请求到达先查过滤器，不存在则直接返回，避免穿透数据库。限流示例：对同一 IP 或同一用户在短时间内的无效请求做计数，超过阈值直接限流或封禁。

六、落地检查清单

上线前确认：过期时间是否加了随机抖动；空值缓存是否设置了较短过期时间；布隆过滤器是否定期重建；热点 Key 是否有互斥锁或逻辑过期；监控告警是否覆盖缓存命中率、Redis 可用性与数据库 QPS；故障演练是否做过 Redis 宕机与批量失效场景。把这些做成固定检查项，雪崩与穿透就很难再打你一个措手不及。

结语：缓存故障很少是单一原因造成的，往往是过期策略、校验缺失与监控不到位同时出现。先分清雪崩、穿透与击穿，再按排查清单定位，最后用随机过期、空值缓存、布隆过滤与限流组合加固，才是可持续的做法。