一、缓存穿透：当查询请求”击穿”所有防线

1.1 问题本质与危害

缓存穿透指查询一个数据库中不存在的数据时，由于缓存层未命中，所有请求直接穿透至数据库层。在恶意攻击或高频无效查询场景下，数据库可能因瞬间承受数万QPS而宕机。例如某电商平台遭遇爬虫攻击，持续请求不存在的商品ID，导致核心数据库服务中断3小时。

1.2 防御技术方案

方案一：空值缓存策略

# 伪代码示例：设置空值缓存
def get_user_info(user_id):
    cache_key = f"user:{user_id}"
    # 1. 先查缓存
    user_data = redis.get(cache_key)
    if user_data is not None:
        return user_data if user_data != "NULL" else None
    # 2. 缓存未命中，查询数据库
    db_data = db.query(f"SELECT * FROM users WHERE id={user_id}")
    # 3. 设置缓存（存在数据设置长过期，不存在设置短过期）
    if db_data:
        redis.setex(cache_key, 3600, json.dumps(db_data))
    else:
        redis.setex(cache_key, 60, "NULL")  # 空值缓存60秒
    return db_data

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

过期时间设置需权衡（建议30-120秒）
需监控空值缓存命中率，避免无效占用内存

方案二：布隆过滤器优化

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

空间效率：1.1%误判率下仅需9.6bits/元素
时间效率：O(k)复杂度（k为哈希函数数量）
局限性：存在误判且不支持删除

实施步骤：

初始化布隆过滤器：bf.create(name, error_rate, initial_capacity)
启动时加载所有有效键：bf.add(name, "key1")
查询前先过滤：if not bf.exists(name, "key1"): return None

二、缓存击穿：热点数据的”瞬间崩溃”

2.1 典型场景分析

当热点键（如首页热门商品）在缓存过期瞬间遭遇高并发请求，所有线程同时穿透至数据库。某直播平台在春晚红包雨期间，因缓存设置不当导致数据库连接池耗尽，造成全局服务不可用。

2.2 解决方案对比

方案一：永不过期策略

// 后台刷新线程示例
@Scheduled(fixedRate = 60000)
public void refreshHotCache() {
    List<String> hotKeys = getHotKeysFromAnalytics(); // 从分析系统获取热点键
    hotKeys.forEach(key -> {
        Object data = db.queryByKey(key);
        redis.set(key, data, -1); // 设置逻辑永不过期
        // 实际通过异步线程更新TTL
        new Thread(() -> {
            Thread.sleep(300000); // 5分钟后更新
            redis.expire(key, 3600);
        }).start();
    });
}

优势：实现简单，彻底避免击穿
风险：需完善的热点发现机制，否则可能缓存过期数据

方案二：互斥锁方案

# 基于Redis单线程特性的互斥锁
def get_with_mutex(key):
    # 尝试获取锁（3秒超时）
    lock_key = f"lock:{key}"
    if redis.set(lock_key, "1", nx=True, ex=3):
        try:
            data = db.query(key)
            if data:
                redis.setex(key, 3600, data)
            return data
        finally:
            redis.delete(lock_key)
    else:
        # 未获取锁，短暂等待后重试
        time.sleep(0.1)
        return get_with_mutex(key)

关键参数：

锁超时时间：需大于业务执行时间（建议3-5秒）
重试间隔：避免CPU空转（建议100-500ms）

三、缓存雪崩：集体失效的”多米诺效应”

3.1 灾难性后果

当大量缓存键在同一时间过期（如设置统一的1小时过期时间），数据库可能遭遇持续数分钟的超载请求。某金融系统在每日0点遭遇雪崩，导致交易处理延迟达15分钟。

3.2 防御体系构建

方案一：分散过期时间

# 在原有TTL基础上增加随机偏移量（示例为0-300秒）
NEW_TTL = BASE_TTL + RANDOM(0, 300)

实施要点：

基础TTL建议按业务周期设置（如商品缓存24小时）
随机范围控制在基础TTL的5%-10%
需监控实际过期时间分布

方案二：多级缓存架构

客户端请求
   ↓
CDN缓存（静态资源）
   ↓
Redis集群（热点数据，TTL=1h）
   ↓
本地缓存（L1 Cache，TTL=5min）
   ↓
数据库

层级设计原则：

L1缓存：内存缓存，毫秒级响应
L2缓存：分布式缓存，支持高并发
各层TTL形成梯度关系（如5min24h）

方案三：熔断降级机制

// 基于Hystrix的缓存熔断实现
@HystrixCommand(
    commandProperties = {
        @HystrixProperty(name="circuitBreaker.requestVolumeThreshold", value="100"),
        @HystrixProperty(name="circuitBreaker.errorThresholdPercentage", value="50"),
        @HystrixProperty(name="circuitBreaker.sleepWindowInMilliseconds", value="5000")
    }
)
public Object getDataWithFallback(String key) {
    try {
        return getDataFromCache(key);
    } catch (Exception e) {
        // 触发熔断后返回默认值
        return getDefaultData(key);
    }
}

关键指标：

请求量阈值：100/窗口期
错误率阈值：50%
熔断时长：5秒

四、最佳实践总结

分层防御体系：结合空值缓存+布隆过滤器防穿透，互斥锁+永不过期防击穿，多级缓存+随机TTL防雪崩
动态监控系统：实时监控缓存命中率、穿透次数、锁等待时间等关键指标
自动化运维：通过定时任务自动更新热点键，动态调整缓存策略
压力测试：模拟缓存失效场景，验证系统承载能力（建议QPS提升3-5倍测试）

通过系统化的缓存策略设计，可使系统在99.9%的场景下避免数据库直接承压，响应时间降低80%以上。实际实施时需结合业务特性调整参数，并通过混沌工程持续验证架构健壮性。

Redis缓存策略深度解析：穿透、击穿与雪崩的应对之道