Redis 缓存击穿排查：热点 Key 过期后如何用互斥锁重建

Redis 缓存很快，但热点 Key 一旦集中失效，问题也会来得很快。某个商品详情、配置开关或首页模块刚好过期，大量请求同时没命中缓存，就会一起打到数据库。几秒钟内，数据库连接数和 QPS 都可能抬头，接口响应也跟着变慢。

这篇文章用一次排查过程讲清楚缓存击穿：我们先看现象，再验证是不是缓存过期导致，最后用互斥锁重建缓存，并给重复请求返回旧值或短暂等待，避免数据库被瞬时流量打满。

问题现场：热点 Key 过期后数据库被打满

我们先看现场。接口平时响应 30ms 左右，突然在某一分钟升到 2s 以上。应用日志里没有明显报错，但数据库连接数迅速升高。Redis 监控显示同一时间缓存命中率掉了一截。

这类现象很像缓存击穿：不是所有 Key 都失效，而是一个或少数热点 Key 刚好过期，所有请求集中回源数据库。

初步判断：是缓存穿透还是缓存击穿

排查 Redis 缓存问题时，经常容易把几个概念混在一起：

这次我们看到的是某个商品详情接口异常，数据库里有这条数据，Redis 里对应 Key 的 TTL 刚好到 0，所以更接近缓存击穿。

动手验证：观察 TTL、命中率和数据库 QPS

先看热点 Key 的 TTL：

TTL product:detail:10086

如果返回 -2，说明 Key 不存在；如果在故障前后经常接近 0，就要重点关注过期瞬间的回源行为。

再看应用日志。可以在缓存读取处加一条临时日志，记录命中和未命中：

String cacheKey = "product:detail:" + productId;
String json = redisTemplate.opsForValue().get(cacheKey);
if (json == null) {
    log.warn("cache miss, key={}", cacheKey);
}

如果短时间内大量相同 Key 都打印 cache miss，而数据库查询也同时升高，基本可以确认是热点 Key 过期后请求同时回源。

定位原因：所有请求同时回源

问题的根因不是 Redis 慢，而是缓存未命中后没有保护。常见代码可能是这样：

public ProductDetail getDetail(Long productId) {
    String cacheKey = "product:detail:" + productId;
    String json = redisTemplate.opsForValue().get(cacheKey);
    if (json != null) {
        return Jsons.toObject(json, ProductDetail.class);
    }

    ProductDetail detail = productMapper.selectDetail(productId);
    redisTemplate.opsForValue().set(cacheKey, Jsons.toJson(detail), Duration.ofMinutes(10));
    return detail;
}

这段代码在低并发下没问题，但热点 Key 过期的一瞬间，所有请求都走到数据库查询。真正需要保护的是“缓存重建”这一步。

修复方案：互斥锁重建缓存并返回旧值

修复思路是：缓存为空时，只有一个请求拿到重建锁并查询数据库；其他请求不要一起查库，可以短暂等待，也可以返回旧值。

一个简化写法如下：

public ProductDetail getDetail(Long productId) {
    String cacheKey = "product:detail:" + productId;
    String lockKey = "lock:product:detail:" + productId;

    String json = redisTemplate.opsForValue().get(cacheKey);
    if (json != null) {
        return Jsons.toObject(json, ProductDetail.class);
    }

    Boolean locked = redisTemplate.opsForValue()
            .setIfAbsent(lockKey, "1", Duration.ofSeconds(10));

    if (Boolean.TRUE.equals(locked)) {
        try {
            ProductDetail detail = productMapper.selectDetail(productId);
            redisTemplate.opsForValue()
                    .set(cacheKey, Jsons.toJson(detail), Duration.ofMinutes(10));
            return detail;
        } finally {
            redisTemplate.delete(lockKey);
        }
    }

    String staleJson = redisTemplate.opsForValue().get(cacheKey + ":stale");
    if (staleJson != null) {
        return Jsons.toObject(staleJson, ProductDetail.class);
    }

    sleepQuietly(100);
    String retryJson = redisTemplate.opsForValue().get(cacheKey);
    if (retryJson != null) {
        return Jsons.toObject(retryJson, ProductDetail.class);
    }

    throw new RuntimeException("please retry later");
}

这里有两个关键点。第一，锁要有过期时间，避免重建请求异常后锁一直存在。第二，旧值兜底需要提前维护，例如写缓存时同时写一个更长 TTL 的旧值 Key。

验证结果：数据库压力回落

修复后，我们可以按下面顺序验证：

1. 手动删除热点 Key，模拟过期。
2. 并发请求同一个商品详情接口。
3. 观察数据库查询次数是否只出现少量回源。
4. 观察 Redis 是否重新写入缓存。
5. 确认接口响应没有大面积超时。

如果同一批请求里只有一个请求查数据库，其他请求返回旧值或等待后命中新缓存，说明缓存击穿已经被控制住。

常见误区和排查清单

• 只加随机 TTL 但不加重建保护：随机 TTL 能减少同时过期，但挡不住单个热点 Key 被打穿。
• 锁没有过期时间：重建失败后可能长期无法刷新缓存。
• 锁时间太短：数据库查询还没结束，锁已经过期，其他请求又开始回源。
• 没有旧值兜底：未拿到锁的请求只能等待，峰值时体验会变差。
• 删除锁不判断归属：复杂场景下可能误删别的请求刚加的锁。

总结一下：Redis 缓存击穿的核心问题，是热点 Key 过期后所有请求同时回源。排查时先看 TTL、缓存命中率和数据库 QPS；修复时给缓存重建加互斥锁，并配合旧值兜底或短暂等待。这样即使热点数据过期，也只有少量请求访问数据库，服务会稳很多。