Redis 用得多了，总绕不开三个经典问题：缓存穿透、缓存击穿、缓存雪崩。这三个词长得像，意思却完全不同，不少刚接触缓存的人容易搞混。这篇就把三个问题逐个拆开聊，从现象到排查到解决，给你一套可以直接落地的处理方案。

缓存穿透说的是，请求查询一个数据库里压根不存在的数据。比如有人拿一个不存在的用户 ID 来查，Redis 里没有，于是去查数据库，数据库也没有，返回空。问题在于，这种请求每次都会穿过缓存直接打在数据库上。如果有人恶意构造大量不存在的 ID 来刷接口，数据库分分钟被拖垮。

和缓存击穿、雪崩的区别在于：穿透是查的数据根本不存在，击穿和雪崩是数据存在但缓存没命中。

线上数据库 CPU 突然飙高，QPS 没什么变化，但慢查询日志里看不到什么有价值的 SQL——因为执行的查询本身就是查不到结果的。打开 APM 或者链路追踪一看，发现某个接口的缓存命中率特别低，接近于零，而请求量却很大。基本可以判断是穿透了。

（未命中次数）是不是异常偏高。如果 miss 数量是 hit 的好几倍，大概率有穿透问题。

 这是最简单的做法。数据库查不到就往 Redis 里写一个空值（比如 

 或者空字符串），设置一个较短的过期时间，比如 60 秒。下次同样的请求过来，Redis 直接返回空值，不再打数据库。

Object value = redis.get(key);
if (value == null) {
    value = db.query(key);
    if (value == null) {
        redis.set(key, "NULL", 60);  // 缓存空值，短过期
    } else {
        redis.set(key, value, 3600);
    }
}

但这方案有个短板：如果攻击者每次用不同的不存在的 ID 来刷，空值缓存命中率很低，因为每个 ID 都是新 key。缓存空值适合穿透的 key 有一定重复率的场景。

 对付大量不重复的无效 key，布隆过滤器更合适。原理是预先把所有合法的 ID 加到一个布隆过滤器里，请求来了先过一遍布隆过滤器，判断这个 key 大概率存不存在。如果布隆过滤器说不存在，那就直接返回，连 Redis 都不用查。

Redis 4.0 以后通过 RedisBloom 模块原生支持布隆过滤器，用起来也方便：

# 初始化布隆过滤器，预计存100万元素，误判率0.1%
BF.RESERVE user_ids 0.001 1000000

# 添加合法ID
BF.ADD user_ids 10001

# 判断是否存在
BF.EXISTS user_ids 10001

布隆过滤器的特点是有一定误判率——它说"存在"可能实际不存在（假阳性），但说"不存在"就一定不存在。用在缓存穿透场景刚好合适：宁可漏过几个不存在的 key 去查数据库，也不能把存在的 key 挡在外面。

实际中两种方案可以结合用：布隆过滤器挡住大部分无效请求，空值缓存兜底那些布隆过滤器误判放行的请求。

缓存击穿：热点 key 过期的瞬间

缓存击穿说的是某个热点 key 突然过期了，同一时刻大量并发请求同时打过来，缓存没了，请求全涌向数据库。和雪崩的区别在于：击穿是一个 key 搞的，雪崩是一大片 key 同时搞的。

最常见的场景：电商首页放了个热门商品的详情缓存，过期时间设了 30 分钟。结果 30 分钟一到，正好赶上流量高峰，几千个请求同时发现缓存没了，一起涌向数据库，数据库连接池直接打满。

这种问题的特征是"瞬时的、周期性的"数据库压力尖峰。你会在监控图上看到一个周期性的锯齿状 CPU 拐点，每次拐点的间隔和你的缓存过期时间吻合。

排查的时候看看慢查询日志里是不是集中在查同一张表的同一个条件，再看看 Redis 的 

 在某个时刻突增，基本就能定位到具体哪个 key。

 最直接的思路：大量请求同时来，只放一个进去查数据库，其他人在外面等着。查完写回缓存，后面的请求就能直接走缓存了。

Object value = redis.get(key);
if (value == null) {
    // 尝试获取锁，设置超时避免死锁
    if (redis.set(lockKey, "1", "NX", "EX", 10)) {
        try {
            value = db.query(key);  // 只有一个请求能走到这里
            redis.set(key, value, 1800);
        } finally {
            redis.del(lockKey);
        }
    } else {
        // 没抢到锁的，稍微等一下重试
        Thread.sleep(50);
        return getData(key);  // 递归重试
    }
}
return value;

互斥锁能挡住数据库压力，但引入了等待，响应时间会变长。极端情况下第一个拿到锁的请求如果挂了，后续的请求得等锁超时才能继续。

 这个方案有点巧妙：不在 Redis 里设 TTL，而是在 value 里存一个逻辑过期时间。请求来了先检查逻辑过期时间，没过期就直接返回。过期了，先返回旧数据，同时异步去刷新缓存。这样用户永远不需要等，但短时间内会拿到稍微旧一点的数据。

CacheData cacheData = redis.get(key);
if (cacheData != null) {
    if (cacheData.getExpireTime().after(new Date())) {
        // 逻辑上没过期，直接返回
        return cacheData.getValue();
    }
    // 逻辑过期了，尝试异步刷新
    if (redis.setnx(refreshLock, "1")) {
        // 拿到刷新锁，异步更新
        executor.submit(() -> {
            try {
                Object newValue = db.query(key);
                cacheData.setValue(newValue);
                cacheData.setExpireTime(...);
                redis.set(key, cacheData);
            } finally {
                redis.del(refreshLock);
            }
        });
    }
    // 先返回旧数据，不等刷新
    return cacheData.getValue();
}

逻辑过期适合对数据实时性要求不极致的场景。用户拿到的是 30 秒前的数据，但请求不会阻塞。对于热点商品详情页这种场景，30 秒延迟完全可以接受。

缓存雪崩：大面积缓存同时失效

缓存雪崩是指一大批 key 在同一时间集体过期，或者 Redis 服务整体宕机，导致请求全部打到数据库。和击穿的区别是规模：击穿是单个热点 key，雪崩是成千上万个 key 同时挂。

典型的坑：批量导入商品数据时，给所有缓存设了相同的过期时间，比如统一 24 小时。24 小时后，几万个 key 同时失效，数据库瞬间被击穿。

雪崩的特征比较明显：监控上数据库 CPU 和连接数突然飙升，同时 Redis 的 

 大幅增加，而且不是个别 key 而是 keyspace 整体命中率断崖式下跌。

如果是 Redis 宕机导致的雪崩，那就更好判断了——Redis 连接直接报错，或者超时。检查 Redis 进程状态、内存使用情况，看是不是 OOM 被 kill 了，或者网络抖动导致大量连接超时。

 这是防雪崩最基础也最有效的手段。设缓存的时候，在基础过期时间上加一个随机值，让 key 的过期时间打散开，别挤在同一时刻。

// 基础过期时间30分钟，加上0-10分钟的随机值
int expire = 1800 + random.nextInt(600);
redis.set(key, value, expire);

就这么简单一行代码，能挡住大部分批量过期导致的雪崩。

 如果雪崩是因为 Redis 挂了，那就得从架构上解决。Redis Sentinel 做主从自动故障转移，或者用 Redis Cluster 做分片和高可用。单节点 Redis 挂了就是雪崩，主从架构至少能扛住主节点故障。

 雪崩一旦发生，数据库被压垮只是时间问题。得有最后一道防线：数据库扛不住的时候，熔断掉对数据库的请求，返回降级数据。

用 Sentinel 或者 Hystrix 配置一个降级策略，当数据库查询失败率超过阈值时，直接走降级逻辑。比如商品详情接口，数据库查不到就返回一个兜底的静态页面，起码首页不白屏。

 对于可预知的大流量场景（比如秒杀、大促），提前把热点数据灌入缓存。系统上线或者 Redis 重启后，主动把核心数据刷进缓存，别等第一次请求来才填充。

最后把三个问题做个区分，方便记忆：

实际线上环境，这三个方案不是二选一，而是组合使用。布隆过滤器挡穿透、互斥锁防击穿、随机过期防雪崩，再配上 Redis 高可用和服务降级做兜底，这套组合拳打下来，缓存层基本就稳了。

还有一个容易被忽略的点：缓存策略不是写完就不管了。线上跑起来要持续关注缓存命中率，一般 95% 以上算健康，低于 90% 就得查一查是不是有异常的未命中模式。用 Redis 的 

，防患于未然总比半夜被拉起来救火强。

Redis缓存三大经典问题的排查与处理

人工智能

本文系统解析缓存三大经典问题：穿透（查询不存在数据）、击穿（热点key过期）、雪崩（批量key失效）。提供布隆过滤器、空值缓存、互斥锁、逻辑过期、随机过期时间等落地方案，并结合高可用架构、熔断降级构建完整防护体系，助你提升缓存命中率至95%以上。

数据库连接池

数据库

Redis

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Redis缓存三大经典问题的排查与处理

Redis缓存三大经典问题的排查与处理

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐