Redis缓存穿透、缓存击穿与缓存雪崩实战指南_Redis

在现代高并发的分布式系统架构中，redis凭借其高性能的内存读写能力，已成为企业级应用不可或缺的缓存中间件。然而，缓存的引入虽然极大地提升了系统响应速度，降低了数据库负载，但也带来了一系列复杂的边缘风险。

一、缓存穿透（cache penetration）

1. 定义与问题
缓存穿透是指查询一个数据库根本不存在的数据。由于缓存中无对应key，请求直接穿透缓存层访问数据库。若大量此类请求存在（如恶意攻击或业务误操作），数据库将承受巨大压力，甚至崩溃。

2. 核心原因

业务逻辑错误：前端未校验请求参数，导致无效key直达数据库。
恶意攻击：黑客故意构造大量不存在的key进行请求。

3. 解决方案
（1）缓存空值

思路：若数据库查询为空，仍将key存入缓存，值为null或特殊标记，并设置较短过期时间（如1分钟）。
优点：简单高效，后续相同请求可直接命中缓存。
缺点：需维护额外空值数据，可能占用空间。
代码示例：

public object getdata(string key) {
    object value = redis.get(key);
    if (value == null) { // 缓存未命中
        value = db.querydata(key); // 查询数据库
        if (value == null) { // 数据不存在
            redis.set(key, "null", 60); // 缓存空值，过期时间1分钟
        } else {
            redis.set(key, value, 3600); // 缓存有效数据，过期时间1小时
        }
    }
    return value;
}

（2）布隆过滤器（bloom filter）[推荐]

思路：使用高效概率型数据结构过滤不存在的请求。布隆过滤器通过多个哈希函数将key映射到位数组，若所有位均为1，则可能存在于数据库；若存在0，则一定不存在。
优点：空间占用极低，过滤效率高。
缺点：存在误判（可能将不存在的key误判为存在），不支持删除操作。
代码示例（guava布隆过滤器）：

bloomfilter<string> filter = bloomfilter.create(funnels.stringfunnel(), 1000000, 0.01); // 容量100万，误判率1%
// 初始化：将数据库所有key预加载到布隆过滤器
filter.putall(db.getallkeys());
public object getdata(string key) {
    if (!filter.mightcontain(key)) { // 布隆过滤器判断不存在
        return null; // 直接返回，不访问数据库
    }
    object value = redis.get(key);
    if (value == null) {
        value = db.querydata(key);
        redis.set(key, value, 3600);
    }
    return value;
}

二、缓存击穿（cache breakdown）

1. 定义与问题
缓存击穿又称热点key问题，指一个访问极其频繁的热点key突然失效，大量并发请求同时穿透缓存，直接冲击数据库。例如，电商平台秒杀商品的缓存过期瞬间，大量用户抢购导致数据库崩溃。

2. 核心原因

热点数据缓存过期时间设置不合理，或手动删除缓存。
高并发请求集中在同一时间点。

3. 解决方案
（1）互斥锁（分布式锁）[推荐]

思路：缓存失效时，仅允许第一个请求获取锁，查询数据库并重建缓存，其余请求等待或返回旧数据。
优点：保证数据一致性，避免并发重建。
缺点：锁竞争可能增加延迟，需防止死锁。
代码示例（redis分布式锁）：

public object getdata(string key) {
    object value = redis.get(key);
    if (value == null) { // 缓存未命中
        if (redis.setnx(key + "_lock", "1", 10)) { // 获取锁，过期时间10秒
            try {
                value = db.querydata(key); // 查询数据库
                redis.set(key, value, 3600); // 重建缓存
            } finally {
                redis.del(key + "_lock"); // 释放锁
            }
        } else { // 未获取锁，等待重试
            thread.sleep(50);
            return getdata(key); // 递归调用
        }
    }
    return value;
}

（2）逻辑过期（不设置物理过期）

思路：缓存数据中增加逻辑过期时间字段，后台线程异步更新缓存，请求仍返回旧数据。
优点：无锁竞争，保证高可用。
缺点：数据短暂不一致，需接受旧数据。
代码示例：

public class cachedata {
    private object data;
    private long expiretime; // 逻辑过期时间戳
}
public object getdata(string key) {
    cachedata data = redis.get(key);
    if (data == null) {
        data = db.querydata(key);
        redis.set(key, data, 3600);
    }
    if (data.expiretime < system.currenttimemillis()) { // 逻辑过期
        thread asyncthread = new thread(() -> {
            // 异步更新缓存
            cachedata newdata = db.querydata(key);
            redis.set(key, newdata, 3600);
        });
        asyncthread.start();
    }
    return data.data;
}

三、缓存雪崩（cache avalanche）

1. 定义与问题
缓存雪崩指大量缓存key同时过期或redis服务宕机，导致所有请求穿透缓存，直接压垮数据库，引发系统瘫痪。例如，电商平台商品缓存统一过期，凌晨用户访问高峰导致mysql崩溃。

2. 核心原因

缓存过期时间设置集中（如批量数据同一时间过期）。
redis单点故障或集群不可用。
系统启动时未预热缓存。

3. 解决方案（分层防御）
（1）过期时间错开

思路：为每个key增加随机过期时间（如基础过期时间 + 随机值），分散失效时间点。
代码示例：

redis.set(key, value, 3600 + new random().nextint(300)); // 基础1小时 + 0-5分钟随机

（2）redis高可用集群

部署哨兵（sentinel）或集群模式：主从自动切换，避免单点故障。
配置限流/熔断：如使用hystrix或sentinel，当redis请求超限时自动降级。

（3）本地缓存兜底

思路：使用caffeine或guava cache作为本地二级缓存，redis宕机时可返回本地数据。
代码示例（caffeine）：

loadingcache<string, object> localcache = caffeine.newbuilder()
    .expireafterwrite(30, timeunit.minutes) // 本地缓存过期30分钟
    .build(key -> redis.get(key));
public object getdata(string key) {
    object value = localcache.get(key);
    if (value == null) {
        value = redis.get(key);
        localcache.put(key, value);
    }
    return value;
}

（4）缓存预热

系统启动时加载热点数据：通过定时任务或启动脚本，提前将高频访问数据加载到redis。
代码示例（伪代码）：

public void warmupcache() {
    list<string> hotkeys = db.gettopnkeys(); // 获取top n热点key
    for (string key : hotkeys) {
        redis.set(key, db.querydata(key), 3600);
    }
}