先分清三种故障
很多网站把 Redis 当成“加速器”：热门商品、文章详情、登录态、配置项、接口结果都会先放进缓存，数据库只在缓存没有命中时再查询。平时这套结构很稳，一旦缓存层出现异常，请求就会集中打到数据库，轻则接口变慢，重则数据库连接被打满。
缓存穿透、缓存击穿和缓存雪崩经常被放在一起说，但它们不是同一个问题。穿透通常是“查不到的数据反复查”；击穿通常是“一个热点 key 突然失效”；雪崩则是“大量 key 或整个缓存集群同时失效”。分清场景，后面的处理才不会乱。
缓存穿透：不存在的数据反复打到数据库
缓存穿透最典型的表现是：用户或爬虫不断请求一个根本不存在的 ID，例如商品 999999999、文章 -1、用户 abc。因为数据库查不到，缓存里也不会保存结果，下一次同样的请求还会继续穿过缓存访问数据库。
解决思路通常有两类。第一类是缓存空结果：数据库确认不存在后，把“空值”也写入缓存，并设置较短过期时间，比如 1 到 5 分钟。第二类是用布隆过滤器提前拦截明显不存在的 key，让请求在进入数据库前就被过滤掉。对于对外接口，还要配合参数校验、限流和风控，避免异常请求无限放大。
缓存击穿：热点 key 失效后的瞬时洪峰
缓存击穿发生在某个特别热门的 key 上。比如首页推荐配置、爆款商品详情、热门活动信息，平时绝大多数请求都命中缓存；但这个 key 到期的一瞬间，大量请求同时发现缓存为空，于是一起访问数据库。
这类问题的重点不是“有没有缓存”，而是“热点失效时有没有保护”。常见做法包括互斥锁重建缓存、逻辑过期、后台异步刷新、热点数据不过期或超长过期。互斥锁的意思是只允许一个请求去查数据库并重建缓存，其他请求短暂等待或返回旧值，避免数据库被瞬间打爆。
缓存雪崩：大量 key 同时失效
缓存雪崩更像系统性故障。它可能来自批量 key 设置了相同过期时间，也可能来自 Redis 实例宕机、网络抖动、内存淘汰策略不合理。雪崩发生时，不是一个热点 key 出问题，而是大量请求同时绕过缓存，数据库压力会突然陡增。
预防雪崩要从结构上处理。给缓存过期时间增加随机抖动，避免同一批 key 同时过期；重要业务使用 Redis 主从、哨兵或集群；对数据库访问增加限流、降级和熔断；核心页面准备静态化或兜底数据。这样即使缓存层短时间异常，业务也不会马上整体不可用。
排查时先看哪些信号
线上怀疑缓存问题时，可以先看几个指标：缓存命中率是否突然下降，Redis QPS 是否异常，数据库慢查询和连接数是否同步升高，某些接口的 P95/P99 延迟是否突然变大。如果只有某个接口异常，可能更接近击穿；如果大量不存在参数带来高频查询，要优先考虑穿透；如果全站多接口一起变慢，就要警惕雪崩或 Redis 可用性问题。
中小业务不一定一开始就要上很复杂的缓存架构，但要提前把监控和兜底准备好。把业务放在 速维云 这类云服务器环境里时，也建议把 Redis、数据库和 Web 服务的监控拆开看：CPU、内存、连接数、网络延迟、慢查询、缓存命中率都要能单独定位，别只盯着“服务器负载高不高”。
真正可靠的是组合拳
缓存不是万能药，它更像数据库前面的一层缓冲区。穿透要拦异常 key，击穿要保护热点 key，雪崩要避免集中失效并准备降级方案。只要把这三类问题拆开处理，大多数缓存事故都能在早期被发现，而不是等到数据库被打满后才临时救火。
