缓存击穿需在redis返回null时立即触发本地缓存兜底，通过concurrenthashmap协调并发加载、redis锁保障db唯一查询，并同步清理两级缓存。
缓存击穿发生时，get 返回 null 就该触发本地缓存兜底
Redis 缓存击穿本质是：热点 key 过期瞬间，大量请求穿透到 DB。单纯加互斥锁（如 SETNX）只能缓解 DB 压力，但没解决重复查询 Redis 的开销和网络延迟。本地缓存（如 Caffeine、Guava Cache）必须在 get 从 Redis 拿到 null 后立即介入，而不是等 DB 查询完再写入——否则仍会有多线程重复加载。
- 本地缓存需设置较短的
expireAfterWrite（比如 2–5 秒），避免与 Redis 过期时间完全对齐导致集体失效 - 不要用
cache.get(key, loader)这种自动加载模式，loader 里再查 Redis + DB 容易造成递归穿透；应显式分三步：查本地 → 查 Redis → 查 DB → 写两级缓存 - 本地缓存容量不宜过大（建议
maximumSize(1000)起步），否则 GC 压力和内存占用不可控
本地缓存未命中时，用 RedissonLock 或 set nx ex 控制 DB 加载唯一性
多个服务实例都发现本地和 Redis 都没数据，必须只让一个线程去查 DB，其余等待结果。直接用 Redis 的 SET key value NX EX 30 最轻量，比引入 RedissonLock 少一层依赖，也避免锁续期逻辑出错。
- 锁 key 应为
"lock:" + cacheKey，过期时间略大于 DB 查询最大耗时（如 3–5 秒），防止锁提前释放引发重复加载 - 拿到锁的线程查完 DB 后，必须原子性地写入 Redis（
SET key value EX 3600）和本地缓存（localCache.put(key, value)） - 没拿到锁的线程不能轮询等待，应使用
Thread.sleep(50)+ 重试本地缓存（最多 2–3 次），避免雪崩式重试压垮 Redis
LocalCache.get(key) 返回 null 不代表真的没数据，要检查是否正在重建
本地缓存本身无“加载中”状态，如果多个线程同时发现本地缓存 miss，又都去争抢 Redis 锁，就退化成单机版缓存击穿。得靠一个并发安全的本地标记来协调。
- 用
ConcurrentHashMap<string completablefuture>></string>记录正在加载的 key，key 存在即表示有人已发起加载 -
LocalCache.get(key)为 null 时，先查这个 map：若存在对应CompletableFuture，直接join()等待结果；若不存在，才尝试加锁并初始化 - 务必在
CompletableFuture完成后清理 map，否则内存泄漏；推荐用whenComplete((v, t) -> map.remove(key))
二级缓存失效不同步时，DEL 操作必须同时触达 Redis 和本地
更新 DB 后删 Redis key 是常规操作，但本地缓存不会自动感知。如果只删 DEL user:123，下次请求仍可能从本地缓存读到脏数据。
- 删 Redis 的同时，必须同步调用
localCache.invalidate("user:123")；不建议用“延迟双删”，本地缓存生命周期短，删了就干净 - 跨 JVM 实例更新时（如 MQ 消息触发），无法直接调用其他节点的
localCache，此时应在消息体中带清除指令，并由各节点监听后执行本地清除 - 避免在事务中删本地缓存——事务回滚后本地缓存已空，但 Redis 还有旧值，状态不一致；应确保 DB 更新成功后再删
本地缓存不是 Redis 的镜像，而是独立一层带时效性的缓冲；它的价值不在容量大小，而在把“同一毫秒内对同一个 key 的多次请求”压缩成一次远程调用。最常被忽略的是：没处理好本地缓存自身的并发加载协调，结果换汤不换药。
