3. 缓存击穿：定义与成因、互斥锁方案、逻辑过期方案、热点数据识别策略

3.1 定义与成因

缓存击穿（Cache Breakdown）是指某个热点 Key 在缓存中恰好过期失效，而此时有大量并发请求同时访问该 Key，导致所有请求直接穿透缓存，瞬间将压力集中到后端数据库（DB），造成数据库负载飙升甚至宕机。

与缓存雪崩（大量 Key 同时失效）不同，击穿聚焦于单个热点 Key 的失效场景。其核心成因包括：

• 热点 Key 过期：业务高峰期，某个高频访问的 Key 到达 TTL 上限，缓存中数据被清除。
• 并发穿透：在 Key 失效的瞬间，大量请求同时到达，缓存层无法命中，全部回源到数据库。
• 重建开销大：该 Key 对应的数据在数据库中查询或计算成本较高（如复杂 SQL、聚合计算），导致 DB 响应变慢，进一步加剧请求堆积。

3.2 互斥锁方案（Mutex Lock）

互斥锁方案的核心思想是：当缓存失效时，只允许一个线程去数据库加载数据，其他线程等待该线程完成加载后，直接从缓存中获取数据。常见的实现方式包括 Redis SETNX 或 Redisson 分布式锁。

3.2.1 流程步骤

1. 请求到达，查询缓存，未命中。
2. 尝试获取分布式锁（如 SETNX lock_key 1 EX 10）。
3. 若获取锁成功，则查询数据库，重建缓存，释放锁。
4. 若获取锁失败，则等待短暂时间（如 50ms）后重试，再次查询缓存。

3.2.2 代码示例（伪代码）

public String getData(String key) {
    String value = redis.get(key);
    if (value != null) {
        return value;
    }
    // 尝试获取分布式锁
    String lockKey = "lock:" + key;
    boolean locked = redis.setnx(lockKey, "1", 10, TimeUnit.SECONDS);
    if (locked) {
        try {
            // 双重检查：防止在等待锁期间，其他线程已重建缓存
            value = redis.get(key);
            if (value != null) {
                return value;
            }
            // 查询数据库
            value = db.query(key);
            redis.set(key, value, 300, TimeUnit.SECONDS);
            return value;
        } finally {
            redis.del(lockKey);
        }
    } else {
        // 未获取到锁，等待后重试
        Thread.sleep(50);
        return getData(key); // 递归重试
    }
}

3.2.3 优缺点对比

3.3 逻辑过期方案（Logical Expiration）

逻辑过期方案不依赖 Redis 的 TTL 物理过期，而是在缓存数据中额外存储一个过期时间字段（逻辑过期时间）。当请求发现数据逻辑过期时，立即返回旧数据，同时异步启动一个线程去更新缓存。该方案的核心是用短暂的数据不一致换取系统的高可用。

3.3.1 数据结构设计

// 缓存中的数据结构
{
  "data": { ... },          // 实际业务数据
  "expireTime": 1700000000  // 逻辑过期时间戳（毫秒）
}

3.3.2 流程步骤

1. 请求到达，查询缓存，获取到数据及逻辑过期时间。
2. 判断当前时间是否大于 expireTime：
• 若未过期：直接返回数据。
• 若已过期：返回旧数据，并尝试获取分布式锁（用于控制只有一个线程执行缓存更新）。
3. 获取锁成功的线程，异步执行缓存重建（查询 DB、更新缓存、更新逻辑过期时间）。
4. 获取锁失败的线程，直接返回旧数据，不等待。

3.3.3 优缺点对比

3.4 热点数据识别策略

要有效防御缓存击穿，首先需要精准识别哪些 Key 属于热点数据。以下是业界常用的识别策略：

3.4.1 识别方法对比

3.4.2 热点数据识别流程图

3.5 方案选型建议