什么是"缓存击穿"（Cache Breakdown）？
📌 定义：
缓存击穿 是指：某个热点 key 在缓存中过期（或不存在）的瞬间，大量并发请求同时发现缓存没有数据，于是全部打到后端数据库（或昂贵服务，如 Milvus、Embedding API）上，导致系统负载骤增甚至崩溃。
实际场景：查询Milvus 向量数据，有个业务需要循环查询同一个向量，所以需要一个缓存下来，但是缓存数据过期后，多线程下大量的请求压力打到数据量，导致性能下降。
什么是"重复计算"（Redundant Computation）？
重复计算 是指：多个线程/请求对同一个输入（如相同的 nodeValue）同时执行相同的昂贵操作（如调用 Embedding 接口、查询 Milvus），而这些操作的结果完全一样，造成资源浪费。
假设 100 个人同时问："'炸鸡' 的向量是什么？"
如果每个人都去调一次 Embedding API（耗时 200ms，收费 $0.001），
那就是 100 次相同计算 → 花了 $0.1，花了 20 秒总 CPU 时间。
但其实 只要算一次，缓存结果，其他人直接用就行。
这就是 重复计算 ------ 明明可以共享结果，却各自重新算一遍。
实际场景：刚上线，大量请求进行请求，但是缓存并未添加完成，导致重复调用。
什么是"双层锁" / "双重检查锁"？
双重检查锁（Double-Checked Locking, DCL） 是一种用于延迟初始化（Lazy Initialization）的并发控制模式。它通过 两次检查 + 加锁 的方式，在保证线程安全的同时，避免每次访问都加锁带来的性能开销。
在代码中：
第一次检查：不加锁，快速判断缓存是否存在。
如果缓存不存在，才加锁；
加锁后 第二次检查：防止多个线程同时进入临界区导致重复初始化。
重点：'锁' 核心在于对资源的加锁，同时进行二次检查。
双重检测锁整体流程
bash
┌───────────────────────┐
│ 开始执行方法 │
└──────────┬────────────┘
▼
┌─────────────────────────────────────┐
│ 第一次检查：cacheService.get(key) ? │
└──────────────────┬──────────────────┘
│
┌──────────────────────┴──────────────────────┐
│ 是（缓存命中） │ 否（缓存未命中）
▼ ▼
┌─────────────────────┐ ┌────────────────────────────┐
│ 设置 rule 并返回 │ │ 获取该 key 对应的 Lock │
└─────────────────────┘ └───────────────┬────────────┘
▼
┌────────────────────────────┐
│ lock.lock() │
└───────────────┬────────────┘
▼
┌─────────────────────────────────────────────┐
│ 第二次检查：cacheService.get(key) ? │
└─────────────────────┬───────────────────────┘
│
┌──────────────────────────────────┴───────────────────────────┐
│ 是（其他线程已加载） │ 否（真正需要加载）
▼ ▼
┌─────────────────────┐ ┌────────────────────────────┐
│ 设置 rule 并返回 │ │ 调用 Embedding + Milvus │
└─────────────────────┘ │ 查询 → 构造 Rule │
│ cacheService.put(key, rule)│
└───────────────┬────────────┘
▼
┌────────────────────────────┐
│ unlock() │
└────────────────────────────┘代码如下：
bash
Rule cacheRule = (Rule) cacheService.get(nodeValue);
if (cacheRule != null) {
rule.setKey(cacheRule.getKey());
rule.setValue(cacheRule.getValue());
log.debug("cacheRule.key:{},cacheRule.value:{}", cacheRule.getKey(), cacheRule.getValue());
return;
}
// 获取该 key 对应的锁，如果没有则创建一个新的锁对象
Lock lock = lockManager.getLock(nodeValue);
// 避免缓存击穿，加锁
lock.lock();
try {
// 第二次检查缓存（关键）
cacheRule = (Rule) cacheService.get(nodeValue);
if (cacheRule != null) {
rule.setKey(cacheRule.getKey());
rule.setValue(cacheRule.getValue());
return;
}
} catch (Exception e) {
throw new RuntimeException(e);
}
long startTimeMilvus = System.currentTimeMillis();
try {
xxx逻辑
//缓存 ，避免多次请求向量数据库
cacheService.put(nodeValue, rule);
} else {
rule.setKey("FALSE");
rule.setValue("FALSE");
}
} else {
rule.setKey("FALSE");
rule.setValue("FALSE");
}
} catch (Exception e) {
log.error("vagueNameReacll error:{}", e);
} finally {
lock.unlock();
}✅ 为什么需要第二次检查？
假设两个线程 A 和 B 同时发现缓存为空：
A 先拿到锁，执行查询并写入缓存；
B 被阻塞在 lock.lock()；
A 释放锁后，B 获取锁 ------ 此时缓存已有数据；
如果 B 不再检查，会 重复执行昂贵的 embedding + Milvus 查询，浪费资源甚至导致数据不一致。
所以 第二次检查是必须的。