Guava Cache 本身不防击穿，必须在外层加互斥逻辑；其 LoadingCache 无内置锁与二次检查，并发 miss 会触发多次 load()；需结合分布式锁、逻辑过期、布隆过滤器前置等多级防护。
Guava Cache 本身不防击穿，必须在外层加互斥逻辑，否则多个线程同时 get(key) 会各自触发 load()，直接打穿到 DB 或 Redis。
Guava 的 LoadingCache 为什么不能单独防击穿
Guava 的 LoadingCache 在 key 未命中时，所有并发调用 cache.get(key) 都会进入 load() 方法——它没有内置锁，也不做二次检查。这和 Caffeine 的 refreshAfterWrite 或同步加载机制完全不同。
常见错误现象：
- 本地缓存过期后，100 个请求同时发现 miss，全部去查 Redis
- Redis 里那个 key 也刚好过期，100 个请求又全去查 DB
- 数据库瞬间收到 100 次相同查询，CPU 直接飙高
所以关键不是“用没用 Guava”，而是“在 cache.get() 之前有没有加分布式锁 + 二次检查”。
必须在 Guava 外包一层互斥读逻辑
正确做法是：把 Guava 当作纯内存容器，所有缓存访问都走统一入口，在这个入口里控制锁、检查、回源、写入的顺序。
实操建议：
- 用
Redisson.getLock("lock:goods:"+key)获取分布式锁，超时设为 3 秒，避免死锁 - 拿到锁后，先查一次 Redis（防止别的线程已写入），再查一次本地缓存（防止本实例刚 reload 过）
- 只有 Redis 和本地缓存都为空，才查 DB；查完后按顺序写 Redis（带逻辑过期字段）、再写 Guava（可设长 TTL 或无 TTL）
- 没拿到锁的线程，不要忙等，
Thread.sleep(10)后重试最多 2 次，否则 fallback 到本地缓存旧值或返回默认值
Redis 层必须用逻辑过期，不能依赖 EXPIRE
物理过期（EXPIRE）会让 key 瞬间消失，导致所有请求在同一毫秒发现 Redis miss，击穿风险反而更高。
逻辑过期才是配合多级缓存的关键：
- 写缓存时，value 存成 JSON：
{"data": {...}, "expireAt": 1729405200000}，key 不设 TTL - 读缓存时，反序列化后判断
expireAt - 过期但抢锁失败，就直接返回旧数据（stale-while-revalidate）；抢锁成功才重建
- 这样即使 Redis 层“过期”，本地缓存仍可兜底，且不会出现大量请求同时重建的雪崩点
布隆过滤器必须前置，不能等请求落到 Guava 再判断
Guava 不知道哪些 key 是非法的，它只管“有”或“没有”。布隆过滤器如果放在 Guava 后面，等于已经放行了非法请求，起不到拦截作用。
部署位置必须是第一道关口：
- 网关层（如 Spring Cloud Gateway + Redis 布隆过滤器）
- 或 service 入口方法最开始，用
bloomFilter.mightContain(key)快速拒绝 - 误判率控制在 1% 以内，参数用
expectedInsertions=100_000, fpp=0.01 - 注意布隆过滤器本身要支持热更新，否则上线新 key 时得全量重建
真正难的不是写几行 cache.get()，而是把锁、过期、空值、布隆这几层时机卡准——早一毫秒漏掉非法 key，晚一毫秒就多一次 DB 查询。这些细节不压测根本看不出问题。
