缓存穿透与击穿：原理差异与高并发解决方案-代码聚汇网

缓存穿透与击穿：原理差异与高并发解决方案

缓存穿透缓存击穿布隆过滤器

|难度：普通|阅读约 13 分钟

1. 缓存穿透与缓存击穿：现象与本质差异

在分布式系统架构中，缓存作为数据库的前置屏障，承担着缓解数据库压力的关键角色。但缓存层设计不当反而会成为系统瓶颈，其中穿透（Cache Penetration）和击穿（Cache Breakdown）是两类典型的高并发场景下的缓存异常。虽然二者都表现为缓存失效，但其触发条件和影响范围存在本质区别。

缓存穿透是指查询一个必然不存在的数据时，由于缓存未命中导致每次请求都直达数据库。这种情况常出现在恶意攻击或业务逻辑缺陷场景，例如用不存在的用户ID频繁查询用户信息。其核心特征是：

查询条件本身不合法（如负数ID、超长字符串）
缓存和数据库均无对应记录
高并发下会导致数据库压力激增

而缓存击穿则是指某个热点key在缓存过期瞬间，突发大量并发请求直接冲击数据库。典型案例包括：

电商平台秒杀商品的库存缓存
新闻网站头条内容的详情缓存
社交平台热搜榜单数据

关键差异点在于：

数据存在性：穿透查询的数据根本不存在，击穿查询的数据是存在的热点数据
并发时机：穿透随时可能发生，击穿仅在缓存过期瞬间爆发
解决方案：穿透需过滤非法请求，击穿需重建缓存并发控制

实际工程中曾遇到一个典型击穿案例：某资讯APP的热门文章详情页设置10分钟缓存过期，当某篇文章突然被大V转发导致流量激增时，缓存过期瞬间数据库QPS从200飙升到12000+，持续约500ms后恢复正常。这种脉冲式压力极易引发数据库连接池耗尽。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 缓存穿透的防御体系构建

2.1 布隆过滤器实现原理

布隆过滤器（Bloom Filter）是应对穿透问题的首选方案，其核心是一个位数组和多个哈希函数。当写入数据时：

对key进行k次不同哈希计算（通常k=3-5）
将每个哈希结果对位数组长度取模，得到位下标
将这些位置为1

查询时用相同哈希函数计算位下标，若所有位均为1则可能存在（可能有误判），任一为0则必定不存在。典型配置下，1亿数据量仅需约120MB内存，误判率可控制在1%以内。

Java实现示例：

java复制// 初始化布隆过滤器
BloomFilter<String> bloomFilter = BloomFilter.create(
    Funnels.stringFunnel(Charset.forName("UTF-8")), 
    1000000, // 预期元素数量
    0.01     // 误判率
);

// 数据预热时加载合法key
for (String validKey : validKeys) {
    bloomFilter.put(validKey);
}

// 查询前校验
if (!bloomFilter.mightContain(key)) {
    return Result.fail("非法请求");
}

2.2 多级校验策略组合

布隆过滤器虽好但存在误判可能，实际工程中需要构建多级防御：

基础参数校验：检查ID是否为正整数、字符串长度是否合理
规则引擎校验：如手机号格式、邮箱正则匹配
布隆过滤器：内存级快速过滤
空值缓存：对确认为不存在的数据，缓存短时间（如2-5分钟）的空结果

特别要注意空值缓存的时间设置不宜过长，否则可能影响正常业务。建议采用动态过期策略：

java复制// 空值缓存设置示例
redisTemplate.opsForValue().set(
    "empty_cache:" + key, 
    "NULL", 
    5 + ThreadLocalRandom.current().nextInt(10), // 5-15分钟随机过期
    TimeUnit.MINUTES
);

3. 缓存击穿的并发控制方案

3.1 互斥锁实现细节

互斥锁方案的核心是只允许一个线程重建缓存，其他线程等待或返回旧值。Redis实现分布式锁需注意：

锁的value需唯一（如UUID），防止误删其他线程的锁
必须设置过期时间（建议10-30秒），避免死锁
获取锁和设置过期时间必须是原子操作

Spring Boot集成Redisson的示例：

java复制public Shop queryWithMutex(Long id) {
    String key = "cache:shop:" + id;
    // 1. 查缓存
    String shopJson = stringRedisTemplate.opsForValue().get(key);
    if (StringUtils.isNotBlank(shopJson)) {
        return JSON.parseObject(shopJson, Shop.class);
    }
    // 2. 判断是否命中空值
    if (shopJson != null) {
        return null;
    }
    
    // 3. 获取分布式锁
    RLock lock = redissonClient.getLock("lock:shop:" + id);
    try {
        // 4. 双重检查
        shopJson = stringRedisTemplate.opsForValue().get(key);
        if (StringUtils.isNotBlank(shopJson)) {
            return JSON.parseObject(shopJson, Shop.class);
        }
        
        // 5. 查数据库
        Shop shop = shopMapper.selectById(id);
        Thread.sleep(200); // 模拟重建耗时
        
        // 6. 写入缓存
        if (shop == null) {
            stringRedisTemplate.opsForValue().set(key, "", 2, TimeUnit.MINUTES);
        } else {
            stringRedisTemplate.opsForValue().set(
                key, 
                JSON.toJSONString(shop), 
                30, 
                TimeUnit.MINUTES
            );
        }
        return shop;
    } finally {
        lock.unlock();
    }
}

3.2 逻辑过期方案实践

逻辑过期将过期时间存储在value中，物理上永不过期。适合价值高、重建成本大的数据：

java复制@Data
public class RedisData {
    private LocalDateTime expireTime;
    private Object data;
}

// 缓存写入逻辑
RedisData redisData = new RedisData();
redisData.setData(shop);
redisData.setExpireTime(LocalDateTime.now().plusSeconds(30));
stringRedisTemplate.opsForValue().set(
    key, 
    JSON.toJSONString(redisData)
);

// 缓存读取逻辑
String json = stringRedisTemplate.opsForValue().get(key);
RedisData redisData = JSON.parseObject(json, RedisData.class);
if (redisData.getExpireTime().isAfter(LocalDateTime.now())) {
    return (Shop) redisData.getData();
}
// 异步重建缓存...

两种方案对比：

维度	互斥锁方案	逻辑过期方案
一致性	强一致	最终一致
复杂度	中（需处理锁）	高（需维护过期字段）
适用场景	数据一致性要求高的场景	允许短暂不一致的热点数据
系统开销	存在线程阻塞	需额外存储过期时间

4. 工程实践中的进阶优化

4.1 热点Key自动探测

通过监控Redis的访问模式，可以自动识别热点Key：

python复制# Redis监控脚本示例
hot_keys = []
for key in redis.monitor():
    if key.access_count > threshold:
        hot_keys.append(key)
        # 自动延长过期时间或标记为逻辑过期

4.2 缓存预热策略

对于已知的热点数据，应在服务启动或流量低谷期主动预热：

定时任务扫描热点数据表
消息队列接收热点变更通知
人工干预接口手动触发加载

4.3 熔断降级机制

当数据库压力超过阈值时，自动触发降级策略：

返回本地缓存或默认值
开启限流模式
触发告警通知运维人员

Hystrix配置示例：

java复制@HystrixCommand(
    fallbackMethod = "getShopFallback",
    commandProperties = {
        @HystrixProperty(name="circuitBreaker.requestVolumeThreshold", value="20"),
        @HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds", value="5000")
    }
)
public Shop getShopById(Long id) {
    // 正常业务逻辑
}

缓存治理是个持续优化的过程，需要结合监控数据不断调整策略。某电商平台的实际数据显示，在实施上述方案后，缓存穿透导致的无效查询降低99.8%，击穿引发的数据库峰值压力下降92%，整体系统可用性从99.9%提升到99.99%。