4. API缓存策略：HTTP缓存头、本地缓存与分布式缓存

缓存是API性能调优中最立竿见影的手段，但也是最容易引发数据不一致和雪崩风险的环节。本章从HTTP协议缓存、应用层本地缓存、分布式缓存三个维度展开，并重点剖析缓存穿透、击穿、雪崩三大经典问题的成因与解决方案。

4.1 HTTP缓存头：让浏览器和网关替你扛流量

HTTP缓存是距离用户最近的缓存层，合理配置Cache-Control和ETag可以大幅减少后端请求量。

// 服务端设置示例（Spring Boot）
@GetMapping("/config")
public ResponseEntity<Config> getConfig() {
    Config config = configService.get();
    return ResponseEntity.ok()
        .cacheControl(CacheControl.maxAge(60, TimeUnit.SECONDS).cachePrivate())
        .eTag(config.getVersion())
        .body(config);
}

4.2 本地缓存 vs 分布式缓存：选型与协同

本地缓存（如Caffeine、Guava Cache）和分布式缓存（如Redis）各有适用场景，实践中常组合使用形成多级缓存。

4.3 缓存穿透、击穿、雪崩：成因与解决方案

这三个问题是缓存系统最典型的故障模式，理解其区别是制定治理策略的前提。

4.3.1 缓存穿透：布隆过滤器与空值缓存

布隆过滤器（Bloom Filter）是一种空间效率极高的概率型数据结构，用于判断一个元素是否可能存在于集合中。它允许一定的误判率（假阳性），但绝不漏判（假阴性率为0）。

// 布隆过滤器使用示例（Guava）
BloomFilter<String> bloomFilter = BloomFilter.create(
    Funnels.stringFunnel(Charset.defaultCharset()),
    100_000,   // 预期插入数量
    0.01       // 期望误判率
);
// 预热：将所有合法ID插入布隆过滤器
for (Long id : validIds) {
    bloomFilter.put(id.toString());
}

// 查询时先检查布隆过滤器
public Object getData(String key) {
    if (!bloomFilter.mightContain(key)) {
        return null; // 直接返回，避免穿透
    }
    // 继续查询缓存和数据库
}

4.3.2 缓存击穿：互斥锁与逻辑过期

热点key过期瞬间，大量并发请求同时回源到数据库。解决方案有两种主流思路：

• 互斥锁（Mutex Lock）：只允许一个线程去加载数据，其他线程等待。适用于对一致性要求高的场景。
• 逻辑过期（Logical Expiration）：缓存永不过期，但数据中携带过期时间字段。异步线程发现过期后主动更新。适用于允许短暂不一致的场景。

// 互斥锁方案（Redis SETNX实现）
public String getWithLock(String key) {
    String value = redis.get(key);
    if (value != null) {
        return value;
    }
    // 尝试获取分布式锁
    String lockKey = "lock:" + key;
    if (redis.setnx(lockKey, "1", 10, TimeUnit.SECONDS)) {
        try {
            // 双重检查：可能其他线程已经加载完成
            value = redis.get(key);
            if (value != null) return value;
            // 回源数据库
            value = db.query(key);
            redis.set(key, value, 300, TimeUnit.SECONDS);
            return value;
        } finally {
            redis.del(lockKey);
        }
    } else {
        // 等待并重试
        Thread.sleep(50);
        return getWithLock(key); // 递归重试
    }
}

4.3.3 缓存雪崩：过期时间打散与多级防护

缓存雪崩的破坏力最大，需要从多个层面联合治理：

1. 过期时间打散：在基础TTL上增加随机偏移量（如±10%~30%），避免大量key同时过期。
2. 多级缓存：本地缓存（L1）作为Redis（L2）的降级方案，即使Redis宕机，L1仍能扛住部分流量。
3. 限流降级：对回源数据库的请求做限流（如Sentinel、Hystrix），超出阈值直接返回降级数据或错误提示。
4. Redis高可用：部署主从+哨兵或Redis Cluster，避免单点故障。

4.4 缓存治理最佳实践清单

• 预热：系统启动时主动加载热点数据到缓存，避免冷启动穿透。
• 监控：监控缓存命中率、回源QPS、Redis内存使用率、大key和热key。
• 大key治理：拆分大value（如超过10KB的字符串或超过5000个元素的集合），避免阻塞Redis单线程。
• 热key发现：使用Redis的hotkeys命令或客户端侧统计，对热key做本地缓存分摊。
• 缓存与DB一致性：优先采用“先更新DB，后删除缓存”策略，配合延迟双删或Binlog监听补偿。