一、缓存穿透：当查询请求”击穿”防护层

1.1 问题本质与典型场景

缓存穿透指查询一个数据库中不存在的数据时，由于缓存层未命中，所有请求直接穿透到数据库层。在恶意攻击场景下，攻击者通过高频请求不存在的键（如用户ID为负数），可导致数据库连接池耗尽甚至服务崩溃。

典型场景包括：

恶意爬虫扫描ID范围
业务逻辑缺陷导致大量无效查询
缓存与数据库数据同步延迟

1.2 防御方案对比与实现

方案一：空值缓存策略

def get_user_info(user_id):
    cache_key = f"user:{user_id}"
    # 1. 先查缓存
    cached_data = redis.get(cache_key)
    if cached_data is not None:
        return deserialize(cached_data) if cached_data != "NULL" else None
    # 2. 查询数据库
    db_data = db.query(f"SELECT * FROM users WHERE id={user_id}")
    if db_data is None:
        # 设置空值缓存，过期时间建议30-60秒
        redis.setex(cache_key, 30, "NULL")
        return None
    # 3. 更新缓存
    redis.set(cache_key, serialize(db_data), ex=3600)
    return db_data

适用场景：适合读多写少且存在大量无效查询的业务

方案二：布隆过滤器方案

布隆过滤器通过位数组和多个哈希函数实现高效存在性判断，其特性包括：

空间效率高（1%误判率时每个元素仅需9.6bits）
查询时间复杂度O(k)（k为哈希函数数量）
不支持删除操作（需使用计数布隆过滤器改进）

实现要点：

初始化阶段将所有有效键存入布隆过滤器
查询时先校验布隆过滤器，不存在则直接返回
动态更新场景需定期重建过滤器（建议双缓冲机制）

1.3 生产环境建议

结合两种方案：布隆过滤器拦截大部分无效请求，空值缓存处理边界情况
监控指标：缓存穿透次数、空值缓存命中率
防御升级：对高频请求实施限流（如令牌桶算法）

二、缓存击穿：热点数据的并发危机

2.1 问题现象与危害

当热点键的缓存过期瞬间，大量并发请求同时穿透到数据库，造成：

数据库CPU飙升至100%
请求响应时间延长3-5个数量级
可能引发连锁故障（如数据库连接池耗尽）

2.2 解决方案详解

方案一：逻辑永不过期

def get_hot_data(key):
    # 主缓存键
    main_key = f"hot:{key}"
    # 锁键
    lock_key = f"lock:{key}"
    # 1. 查询主缓存
    data = redis.get(main_key)
    if data is not None:
        # 检查逻辑过期时间（存储在数据体中）
        if is_valid(data):
            return data
    # 2. 尝试获取分布式锁
    if redis.set(lock_key, "1", nx=True, ex=10):
        try:
            # 查询数据库
            fresh_data = db.query(f"SELECT * FROM hot_data WHERE id={key}")
            if fresh_data:
                # 设置逻辑过期时间（如30分钟后）
                fresh_data["expire_at"] = time.time() + 1800
                redis.set(main_key, serialize(fresh_data))
            return fresh_data
        finally:
            redis.delete(lock_key)
    else:
        # 等待50ms后重试
        time.sleep(0.05)
        return get_hot_data(key)

关键点：

数据中存储逻辑过期时间而非直接设置TTL
使用SETNX实现分布式锁
锁超时时间需大于业务处理时间

方案二：后台异步续期

实现要点：

热点数据标记：通过监控系统识别热点键（如访问频率>1000次/分钟）
定时任务：每分钟扫描即将过期的热点键
异步更新：使用消息队列实现非阻塞更新

2.3 性能对比

方案	吞吐量	实时性	实现复杂度
逻辑永不过期	高	中	中
后台异步续期	极高	低	高
互斥锁方案	中	高	低

三、缓存雪崩：系统性崩溃的连锁反应

3.1 灾难场景还原

当大量缓存键在同一秒过期时，系统将经历：

时间轴：
0s: 缓存集群中80%的键同时过期
10ms: 数据库请求量从1000QPS飙升至50000QPS
50ms: 数据库连接池耗尽，新请求开始排队
200ms: 上游服务超时，引发雪崩效应

3.2 防御体系构建

3.2.1 分散过期时间

def set_with_random_expire(key, value, base_ttl=3600):
    # 在基础TTL上增加0-600秒随机偏移
    random_offset = random.randint(0, 600)
    ttl = base_ttl + random_offset
    redis.setex(key, ttl, value)

最佳实践：

基础TTL建议设置为业务高峰期的2-3倍
随机偏移量应占TTL的10%-20%
对一致性要求高的数据，可缩小偏移范围

3.2.2 多级缓存架构

典型三层架构：

本地缓存（Caffeine/Guava）：存储热点数据，TTL<10秒
分布式缓存（Redis）：存储全量数据，TTL分钟级
数据库：作为最终数据源

数据同步策略：

写操作：先更新数据库，再删除各级缓存（Cache Aside模式）
读操作：本地缓存未命中→分布式缓存→数据库

3.2.3 熔断降级机制