凌晨三点，我被电话惊醒：
“苏工！首页崩了！” 监控显示：缓存命中率 0%，数据库 QPS 10 万 +，线程阻塞 2000+。
根本原因竟是同事没加缓存！
不会用缓存的程序员，就像不会刹车的赛车手 —— 今天这 10 条军规，能救你的系统！

10 条缓存黄金军规（血泪总结）

1 避免大 Key：别把缓存当垃圾桶！

• 反例：缓存整个用户对象（含订单记录等），引发内存碎片和 Full GC。
• 正解：拆！基础信息（user_base）和扩展信息（user_detail）分开缓存。

@Cacheable(value = "user_base", key = "#id") // 只存核心字段  
public UserBase getBaseInfo(Long id){...}

2 永远设置过期时间！

• 血案：配置信息永不过期，修改后 3 天才生效。
• 公式：最优TTL = 平均数据变更周期 × 0.3
• 技巧：基础 TTL + 随机抖动（如 30 分钟 + 随机 5 分钟），防集中失效！

3 批量失效 = 自爆！

• 事故：所有缓存同时间失效，数据库瞬间被打穿。
• 方案：TTL 增加随机值，让缓存均匀过期：

public long randomTtl(long baseTtl){  
    return baseTtl + new Random().nextInt(300); // 加0-5分钟随机值  
}

4 空值缓存：防穿透利器

• 场景：恶意请求不存在的 ID（如用户 ID=-1），穿透缓存压垮 DB。
• 方案：缓存空值标记（如 "empty"），5 分钟内直接返回：

if(product == null){  
    redis.setex(key, 300, "empty"); // 空值缓存5分钟  
}

5 热点数据预加载

• 绝招：用 Redis HyperLogLog 实时统计访问频率，定时预加载热点数据：

// 每10秒检测一次热点  
@Scheduled(fixedRate = 10000)  
public void detectHotKeys(){  
    if(redis.pfcount(key) > 1000) preloadData();  
}

6 分布式锁：认准 Redisson！

• 陷阱：手写 Redis 锁易踩坑（死锁、超时）。
• 正解：用 Redisson，3 行代码搞定：

RLock lock = redisson.getLock("lock:"+key);  
if(lock.tryLock(3, 30, SECONDS)){...} // 自动续期  
finally{ lock.unlock(); }

7 延迟双删：保数据一致性

• 场景：先更数据库还是先删缓存？两难！
• 方案：先删缓存 → 更新 DB → 延时 500ms 再删一次：

redis.delete(key);  
productDao.update(product);  
executor.schedule(() -> redis.delete(key), 500, MILLISECONDS);

8 数据结构选错 = 性能灾难

• 血泪：用 String 存整个 User 对象，更新 1 个字段需全量读写！
• 正解：计数器 / 锁 → String商品属性 → Hash（支持字段级更新）排行榜 → ZSet（自动排序）

9 熔断降级：缓存挂了也不慌

• 核心：用 Hystrix/Sentinel 兜底，返回默认数据保命：

@HystrixCommand(fallbackMethod = "getProductFallback")  
public Product getProduct(Long id){...}  

public Product getProductFallback(){  
    return new Product().setDefault(); // 兜底数据  
}

终极忠告：缓存是双刃剑！

• 灵魂三问：
  1 真的需要缓存吗？
  2 方案是否完整？（穿透 / 雪崩 / 击穿）
  3 有熔断兜底吗？

缓存用得好是核弹级优化，用不好是核弹级灾难！

缓存治理黄金法则（速存！）

最后警告：
当你摩拳擦掌要加缓存时，先问自己 ——
“如果缓存此刻崩溃，我的系统能活过 1 分钟吗？”
没有兜底的缓存，就是埋雷！