3. 缓存击穿与互斥锁：热点key击穿场景、分布式互斥锁实现、SETNX与Redisson方案、锁超时与续期机制

3.1 热点Key击穿场景与问题分析

缓存击穿（Cache Breakdown）特指单个热点Key在缓存中过期失效的瞬间，大量并发请求同时穿透缓存直达数据库，导致数据库负载瞬间飙升甚至宕机。与缓存雪崩（大量Key同时失效）不同，击穿聚焦于单一热点资源的失效瞬间。

下图展示了热点Key失效瞬间的并发穿透路径：

3.2 分布式互斥锁实现原理

解决缓存击穿的核心思路是互斥锁（Mutex Lock）：只让一个请求去数据库加载数据，其他请求等待或快速失败。在分布式环境下，必须使用分布式互斥锁来协调多个进程/实例。

3.3 SETNX方案：基础实现与缺陷

Redis的SETNX（SET if Not eXists）是最基础的分布式锁实现方式。其核心命令为：

// 加锁：key不存在时设置成功，返回1；已存在则返回0
SETNX lock_key unique_value

// 设置过期时间（防止死锁）
EXPIRE lock_key 30

// 解锁：校验唯一值后删除
if redis.get("lock_key") == unique_value:
    redis.del("lock_key")

基础SETNX方案存在以下关键缺陷：

3.4 Redisson方案：成熟的企业级实现

Redisson是Redis官方推荐的Java分布式锁框架，提供了完整的互斥锁、读写锁、信号量等实现。其核心优势在于自动续期（Watchdog）和可重入机制。

// Redisson分布式锁使用示例
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
RedissonClient redisson = Redisson.create(config);

RLock lock = redisson.getLock("hotKey:lock");
try {
    // 尝试加锁，最多等待10秒，锁自动过期30秒
    if (lock.tryLock(10, 30, TimeUnit.SECONDS)) {
        // 回源加载数据到缓存
        String value = loadFromDB("hotKey");
        cache.set("hotKey", value, 60);
    } else {
        // 获取锁失败，从缓存获取旧数据或快速失败
        return cache.get("hotKey");
    }
} finally {
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

Redisson与基础SETNX方案的核心差异：

3.5 锁超时与续期机制（Watchdog）

锁超时是分布式锁最棘手的工程问题：超时时间设置过短，业务未完成锁已释放；设置过长，锁持有者崩溃后其他线程长时间等待。Redisson的Watchdog机制优雅地解决了这一矛盾。

下图展示了Watchdog的续期流程与锁状态转换：

3.6 互斥锁方案对比与选型建议

3.7 缓存击穿互斥锁的完整流程

综合上述技术，一个健壮的缓存击穿防护流程应包含以下步骤：

1. 读缓存：尝试从Redis获取热点Key，命中则直接返回。
2. 本地标记：检查本地内存标记（如Caffeine），防止同一实例内重复回源。
3. 分布式锁：尝试获取Redisson锁（key=热点Key+锁后缀）。
4. 双重检查：获取锁后再次检查缓存（防止等待期间其他线程已加载）。
5. 回源加载：查询数据库，将结果写入缓存，设置合理TTL。
6. 释放锁：业务完成后释放分布式锁，Watchdog自动停止续期。
7. 返回数据：将数据返回给调用方。