一、缓存穿透：当查询成为攻击武器

1.1 问题本质与危害

缓存穿透指查询数据库中不存在的数据时，缓存层无法提供防护，所有请求直接穿透至数据库。在恶意攻击场景下，攻击者通过高频请求不存在的键值（如用户ID为负数），可导致数据库连接池耗尽甚至服务崩溃。某电商平台曾因未对非存在商品ID做防护，遭受缓存穿透攻击后数据库QPS激增300倍。

1.2 防御策略详解

空值缓存方案

// 设置空值缓存示例（Java伪代码）
public String getData(String key) {
    String value = cache.get(key);
    if (value == null) {
        value = db.query(key);
        if (value == null) {
            // 设置空值缓存，过期时间30秒
            cache.setex(key, "", 30);
            return null;
        }
        cache.set(key, value);
    }
    return value;
}

该方案通过缓存空值减少数据库查询，但需注意：

过期时间设置需权衡安全性与存储成本
适用于读多写少场景，写频繁时可能产生脏数据

布隆过滤器方案

布隆过滤器通过位数组和哈希函数实现高效键值存在性判断，具有以下特性：

空间效率高：10亿数据仅需约1GB内存
误判率可控：典型场景下误判率<0.01%
无法删除：需定期重建过滤器

实施步骤：

初始化时将所有有效键存入布隆过滤器
查询前先检查过滤器，不存在则直接返回
定期同步数据库变更到过滤器

1.3 方案对比与选型

方案	适用场景	资源消耗	实现复杂度
空值缓存	查询模式相对固定的业务	低	简单
布隆过滤器	海量数据且允许一定误判的场景	中	复杂

二、缓存击穿：热点数据的致命瞬间

2.1 击穿现象解析

当热点键缓存过期时，大量并发请求同时发现缓存失效，形成请求洪峰直击数据库。典型场景包括：

秒杀活动商品库存查询
热门新闻详情页访问
社交平台热点话题数据

2.2 解决方案矩阵

永不过期策略

通过后台线程定期刷新缓存，实现逻辑上的”永不过期”：

# Python后台刷新示例
def refresh_hot_key(key):
    while True:
        value = db.query(key)
        cache.set(key, value, 3600)  # 设置1小时过期
        time.sleep(300)  # 每5分钟刷新

需注意：

刷新间隔需小于业务容忍的最长不一致时间
需处理线程异常终止情况

互斥锁方案

// Redis互斥锁实现（Redisson示例）
public String getHotData(String key) {
    String value = cache.get(key);
    if (value == null) {
        RLock lock = redisson.getLock(key + ":lock");
        try {
            if (lock.tryLock(1, 10, TimeUnit.SECONDS)) {
                value = db.query(key);
                cache.set(key, value);
            }
        } finally {
            lock.unlock();
        }
    }
    return value;
}

关键参数说明：

等待时间1秒：避免长时间阻塞
锁持有时间10秒：需大于业务处理时间
需处理锁获取失败的情况

2.3 性能优化技巧

本地缓存辅助：在应用层增加Guava Cache等本地缓存
请求限流：对热点数据访问进行速率限制
预加载机制：提前加载即将过期的热点数据

三、缓存雪崩：集体失效的灾难

3.1 雪崩形成机理

当大量缓存键的过期时间集中在某个时间段，且这些键同时失效时，数据库将承受瞬间峰值压力。某金融系统曾因所有缓存设置相同过期时间，导致每日凌晨3点出现周期性雪崩。

3.2 防御体系构建

随机过期时间策略

-- Lua脚本实现随机过期时间（Redis）
local value = redis.call("GET", KEYS[1])
if value then
    local ttl = math.random(300, 900)  -- 5-15分钟随机
    redis.call("EXPIRE", KEYS[1], ttl)
    return value
end

实施要点：

基础过期时间需大于业务最长处理时间
随机范围需根据业务特性调整
避免过期时间设置过短导致频繁重建

多级缓存架构

典型分层设计：

本地缓存（Caffeine/Guava）：TTL 1分钟
分布式缓存（Redis）：TTL 10分钟
数据库持久层

数据同步流程：

写操作依次更新各层缓存
读操作优先从本地缓存获取
本地缓存缺失时访问分布式缓存
所有缓存缺失时查询数据库并重建各级缓存

3.3 监控与告警体系

建议配置以下监控指标：

缓存命中率：低于80%需警惕
数据库查询延迟：突增可能预示雪崩
缓存键数量变化：异常下降可能表明大量过期
错误日志：频繁的缓存获取失败记录

四、数据一致性：缓存与数据库的永恒博弈

4.1 一致性模型选择

模型	特点	适用场景
强一致性	缓存与DB实时同步	金融交易等敏感业务
最终一致性	允许短暂不一致	社交动态等非实时业务
监听式更新	通过消息队列异步更新	高并发写场景

4.2 典型实现方案

Canal监听方案

数据库开启binlog
Canal服务解析binlog事件
将变更事件推送到消息队列
消费者更新缓存

// Canal消费者示例
@KafkaListener(topics = "db_change")
public void handleDbChange(ConsumerRecord<String, String> record) {
    ChangeEvent event = parseEvent(record.value());
    if (event.isUpdate()) {
        cache.set(event.getKey(), event.getNewValue());
    } else if (event.isDelete()) {
        cache.del(event.getKey());
    }
}

双写一致性方案

# 事务性双写示例
def update_data(key, new_value):
    try:
        # 开启数据库事务
        with transaction.atomic():
            db.update(key, new_value)
            # 缓存更新失败时回滚数据库
            if not cache.set(key, new_value):
                raise Exception("Cache update failed")
    except Exception as e:
        # 异常处理逻辑
        log.error(f"Update failed: {e}")

4.3 性能优化建议

批量操作：合并多个缓存更新为一次批量操作
异步化：非关键路径的缓存更新可采用异步方式
失败重试：建立重试机制处理短暂性故障
版本控制：为缓存数据添加版本号，解决并发更新问题

五、最佳实践总结

分级防御体系：结合空值缓存、布隆过滤器、互斥锁等多层防护
过期时间策略：采用基础时间+随机偏移的方式避免集体失效
监控预警机制：建立完善的缓存指标监控体系
异步更新优先：非实时性要求高的场景优先采用异步更新
容量规划：根据业务特性预估缓存容量需求，预留20%余量

通过系统化应用上述策略，某在线教育平台成功将数据库压力降低85%，系统响应时间从平均500ms降至80ms以内。缓存架构的优化不仅是技术实现，更需要结合业务特性进行针对性设计，在性能、成本、一致性之间找到最佳平衡点。

Redis缓存优化实战：破解四大性能瓶颈