3. 缓存击穿与互斥锁：热点key击穿场景、分布式互斥锁实现、锁超时与重试机制

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

缓存击穿（Cache Breakdown）特指单个热点Key在缓存中过期失效的瞬间，大量并发请求同时穿透缓存，直接打到后端数据库，导致数据库负载瞬间飙升甚至宕机。与缓存雪崩（大量Key同时失效）不同，击穿是单点高并发问题。

3.2 分布式互斥锁实现方案

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

3.2.1 基于Redis的SET NX + EX实现

最基础的分布式锁使用 Redis 的 SET key value NX EX timeout 命令，保证原子性加锁与过期时间设置。

// 加锁：SET NX EX 原子操作
String lockKey = "lock:hotkey:product_123";
String requestId = UUID.randomUUID().toString();
Boolean locked = redisTemplate.opsForValue()
    .setIfAbsent(lockKey, requestId, 5, TimeUnit.SECONDS);

if (Boolean.TRUE.equals(locked)) {
    try {
        // 从数据库加载数据
        Object data = db.query("SELECT * FROM product WHERE id = ?", productId);
        // 回填缓存
        redisTemplate.opsForValue().set("cache:product_123", data, 30, TimeUnit.SECONDS);
        return data;
    } finally {
        // 释放锁：使用Lua脚本保证原子性
        String luaScript = 
            "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "  return redis.call('del', KEYS[1]) " +
            "else " +
            "  return 0 " +
            "end";
        redisTemplate.execute(
            new DefaultRedisScript<Long>(luaScript, Long.class),
            Arrays.asList(lockKey), requestId
        );
    }
} else {
    // 未获取到锁：等待重试或直接返回旧缓存
    Thread.sleep(50);
    // 重试或降级逻辑
}

3.2.2 主流分布式锁方案对比

3.3 锁超时与重试机制设计

分布式锁在实际运行中面临两个核心挑战：锁超时导致业务未完成锁被释放，以及获取锁失败后的重试策略。设计不当会引发数据不一致或死锁。

3.3.1 锁超时处理：看门狗机制

业务执行时间超过锁的过期时间时，锁自动释放，其他线程获取锁后可能读到不一致数据。Redisson 的看门狗（Watch Dog）机制是业界主流解法：

• 默认行为： 锁过期时间 30 秒，每 10 秒检查一次业务是否仍在执行。
• 续期逻辑： 如果业务未完成，自动将锁过期时间重置为 30 秒。
• 异常保护： 如果持有锁的线程崩溃，看门狗停止续期，锁在 30 秒后自动释放。

// Redisson 看门狗示例
RLock lock = redissonClient.getLock("lock:hotkey:product_123");
try {
    // 默认过期时间 30 秒，看门狗自动续期
    lock.lock(30, TimeUnit.SECONDS);
    // 业务逻辑可能执行 60 秒，看门狗会在 10 秒、20 秒、30 秒... 续期
    Object data = loadDataFromDB(productId);
    cacheData(productId, data);
} finally {
    // 业务完成，手动释放锁
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

3.3.2 重试机制设计

获取锁失败时，不能无限重试，必须设计合理的退避策略：

3.4 互斥锁解决缓存击穿完整流程

下图展示了使用分布式互斥锁解决缓存击穿的完整决策流程：

3.5 安全合规视角下的锁设计约束

在金融、电商等合规敏感场景中，分布式锁的设计必须满足以下约束：

• 可观测性： 所有加锁、解锁、续期、重试操作必须记录审计日志，包含 requestId、时间戳、业务标识。
• 死锁防护： 锁必须有绝对最大生存时间（TTL），即使看门狗失效，锁也必须在 TTL 后自动释放。
• 幂等性： 同一 requestId 重复加锁应返回成功（可重入锁），防止重试导致数据重复加载。
• 数据一致性： 锁释放后，其他线程读取到的缓存数据必须是完整的、一致的，不能出现半写状态。

3.6 总结与核心要点