高并发下缓存策略的实战：从雪崩击穿穿透到混合架构的取舍

在微服务架构中，缓存早已不是锦上添花的选项，而是高并发系统的生存基石。从 Spring Boot 的 @Cacheable 到 Redis 集群，开发者们习惯于将热点数据提前加载，以换取数据库层的喘息。然而，社区讨论中频繁出现的“缓存抖动”和“全链路阻塞”案例表明，频繁的数据库查询和缓存失效依然是系统的痛点。为什么加了 Redis，系统依然会崩溃？为什么热点数据更新了，Redis 却没变？这不仅仅是配置问题，更是一场关于性能、一致性与可用性的博弈。

核心判断：在绝大多数高并发场景下，本地缓存 + 分布式缓存 的二级混合架构是目前性价比最高的方案，它有效平衡了单机的速度与大集群的数据一致性。

现象：为什么缓存会失效？

缓存失效并非单一原因，而是三种典型攻击或故障的综合体现。首先是缓存雪崩，这通常发生在系统对大量 Key 设置了相同的过期时间时。例如，一个秒杀活动在 0 点开始，所有商品的缓存过期时间都设置为 0 点，导致大量请求瞬间穿透到数据库，引发数据库 CPU 飙升至 100%。其次是缓存击穿，针对极少量的“热点 Key”，在 Key 过期的瞬间，由于并发请求量巨大，所有请求同时击穿缓存，直接打到数据库。最后是缓存穿透，指的是查询一个根本不存在的数据，缓存和数据库都没有命中，导致每次请求都绕过缓存查库。如果这种请求持续涌入（如恶意攻击或爬虫），数据库连接池会被迅速耗尽。

方案与取舍：混合架构的博弈

面对上述挑战，单纯的 Redis 无法解决所有问题。本地缓存（如 Caffeine）速度快（纳秒级），但容量受限且无法在集群间共享；分布式缓存（如 Redis）容量大且共享，但存在网络延迟和一致性难题。我们需要在两者之间做出取舍。

在实际工程实践中，混合架构的核心逻辑是：请求先查本地缓存，未命中则查 Redis，再未命中查数据库并回填。这种二级结构极大地降低了网络 IO 次数和 Redis 压力，但引入了数据一致性的新难题：本地缓存更新后，如何在 Redis 中同步失效？这需要精心设计的策略。

实践：三招防御与实现

为了防止缓存穿透和击穿，我们通常采用“布隆过滤器”和“互斥锁”两种手段。

1. 布隆过滤器（解决穿透）：在查询数据库前，先通过布隆过滤器判断 Key 是否可能存在。如果过滤器判断 Key 肯定不存在，则直接返回，不查询数据库。这需要配合 Redis 的 Set 操作。

2. 互斥锁（解决击穿）：对于热点 Key 的过期，不能让所有线程都去查库。可以使用 Redis 的 SETNX 命令或者 Java 的 ReentrantLock 实现互斥锁，只允许一个线程去查询数据库并回填缓存，其他线程等待结果。

3. 缓存预热（解决雪崩）：在系统启动或重启前，主动将可能的热点 Key 载入缓存，并设置稍有不同的随机过期时间，避免集体失效。

下面是一个基于 Spring Boot 和 Redis 的伪代码实现逻辑，展示了如何利用互斥锁防止缓存击穿：

@GetMapping("/goods/{id}")
public Goods getGoods(@PathVariable Long id) {
    // 1. 先查本地缓存
    Goods goods = localCache.get(id);
    if (goods != null) {
        return goods;
    }

    // 2. 本地未命中，查 Redis
    goods = redisTemplate.opsForValue().get("goods:" + id);
    if (goods != null) {
        localCache.put(id, goods); // 回填本地
        return goods;
    }

    // 3. 分布式缓存未命中，加锁查 DB
    String lockKey = "lock:goods:" + id;
    try {
        boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 10, TimeUnit.SECONDS);
        if (locked) {
            goods = goodsMapper.selectById(id);
            if (goods != null) {
                redisTemplate.opsForValue().set("goods:" + id, goods, 300, TimeUnit.SECONDS);
                localCache.put(id, goods);
            }
        } else {
            // 获取锁失败，等待片刻后重试
            Thread.sleep(50);
            return getGoods(id); // 递归重试
        }
    } finally {
        // 释放锁（需注意设置过期时间防死锁）
        redisTemplate.delete(lockKey);
    }
    return goods;
}

监控与调优：不要陷入“缓存依赖症”

实施缓存策略后，不能一劳永逸。我们需要引入监控体系（如 Prometheus + Grafana）来关注缓存命中率。如果命中率过低，说明缓存策略失效；如果命中率过高且数据库压力骤减，说明可能存在缓存数据陈旧的问题。

$命中率 = \frac{缓存命中次数}{总查询次数}$

同时，要警惕“缓存依赖症”。过于依赖缓存会导致在缓存不可用（如 Redis 挂了）时系统直接瘫痪。因此，必须实现降级策略。当缓存服务不可用时，系统应能快速切换至只读数据库模式或返回默认兜底数据，保证核心业务流程的可用性，而不是让用户看到 500 错误。

总结与讨论

缓存策略是微服务性能优化的必经之路，但也是风险重重的领域。选择混合架构并不意味着一劳永逸，它要求我们在高性能与强一致性之间走钢丝。我们需要根据业务场景（如金融交易对一致性要求高，而新闻资讯对实时性要求低）来动态调整 TTL（过期时间）和淘汰策略。

开放讨论问题：在你的项目中，遇到过的最大缓存问题是什么？你是通过天然的业务特性（如数据不常变）还是通过技术手段（如布隆过滤器、异步更新）解决的？欢迎在评论区分享你的实战经验。