Redis 缓存雪崩、穿透、击穿怎么解决?

Redis 缓存雪崩、穿透和击穿是缓存使用中常见的三个问题，它们都可能导致数据库压力骤增，甚至系统崩溃。下面分别解释这三个问题的原因、危害以及相应的解决方案。

1. 缓存雪崩 (Cache Avalanche)

问题描述:

缓存雪崩是指在某一时刻，缓存中大量的 Key 同时过期失效，导致大量的请求直接穿透缓存，全部打到数据库上，造成数据库压力瞬间增大，甚至宕机。就像雪崩一样，一旦发生，后果严重。

原因:

• 大量 Key 设置了相同的过期时间: 这是最常见的原因。例如，在某个时间点，批量导入的数据设置了相同的过期时间，导致它们在同一时刻失效。
• 缓存服务宕机: 如果 Redis 集群发生故障，导致缓存服务不可用，所有请求都会直接打到数据库。
• 热点数据集中过期: 虽然不是所有 Key 都过期，但如果大量热点数据 Key 在同一时间过期，也会造成类似雪崩的效果。

危害:

• 数据库压力骤增: 大量请求直接访问数据库，可能导致数据库连接耗尽、性能下降甚至宕机。
• 系统崩溃: 数据库宕机可能导致整个系统崩溃，影响用户体验。
• 服务不可用: 系统崩溃或数据库压力过大，会导致服务不可用。

解决方案:

• 过期时间打散 (设置随机过期时间):
• 原理: 在设置缓存 Key 的过期时间时，加上一个随机值，避免大量的 Key 在同一时刻过期。
• 实现: 例如，如果原本设置过期时间为 1 小时，可以改为 1 小时 ± 随机几分钟。
• 代码示例 (Java):
• java复制代码
• long expireTime = 60 * 60; // 1 小时 long randomTime = new Random().nextInt(60 * 5); // 随机 0-5 分钟 redisTemplate.expire(key, expireTime + randomTime, TimeUnit.SECONDS);
• 互斥锁 (Mutex) 或分布式锁:
• 原理: 当缓存失效时，只允许一个请求去重建缓存，其他请求等待重建完成，避免大量请求同时穿透缓存。
• 实现: 可以使用 Redis 的 SETNX 命令实现分布式锁。
• 流程:请求到达，查询缓存，如果缓存失效。尝试获取分布式锁 (例如 SETNX key_lock value NX PX 5000)。如果获取锁成功，则从数据库加载数据，重建缓存，释放锁。如果获取锁失败，则等待一段时间 (例如几毫秒) 后重试查询缓存。
• 注意: 需要设置锁的过期时间，防止死锁。
• 缓存预热 (Cache Preheating):
• 原理: 在系统启动或低峰期，提前将热点数据加载到缓存中，避免在高峰期缓存失效导致雪崩。
• 实现: 可以使用定时任务、监控系统等方式，定期加载或更新缓存。
• 场景: 适用于已知热点数据且数据更新频率不高的情况。
• 双层缓存 (Multi-Level Cache):
• 原理: 使用多级缓存，例如本地缓存 (如 Caffeine) + Redis 缓存。当 Redis 缓存失效时，先从本地缓存获取数据，本地缓存也失效时才穿透到数据库。
• 实现: 可以使用 Caffeine、Guava Cache 等本地缓存库。
• 优点: 本地缓存速度更快，可以有效缓解 Redis 缓存失效带来的冲击。
• 缺点: 本地缓存容量有限，数据一致性需要考虑。
• 服务降级 (Service Degradation) 或限流 (Rate Limiting):
• 原理: 当检测到缓存雪崩可能发生时，对部分请求进行降级处理 (例如返回默认值、错误页) 或限流，保护数据库。
• 实现: 可以使用熔断器、限流组件 (如 Sentinel、Guava RateLimiter) 等。
• 场景: 作为最后的保护手段，牺牲部分用户体验来保证系统整体可用性。

2. 缓存穿透 (Cache Penetration)

问题描述:

缓存穿透是指请求查询的 Key 在缓存和数据库中都不存在，导致每次请求都穿透缓存，直接打到数据库。由于数据库也查不到数据，每次请求都会无效查询数据库，浪费资源，在高并发情况下可能导致数据库压力过大。

原因:

• 恶意攻击: 攻击者故意构造大量不存在的 Key 进行请求，试图绕过缓存，直接攻击数据库。
• 业务误操作: 程序 Bug 导致查询不存在的 Key。
• 数据清理不彻底: 数据库中数据被删除，但缓存中没有同步清理，导致缓存中不存在，数据库也不存在。

危害:

• 数据库压力增大: 大量无效请求直接访问数据库，浪费数据库资源。
• 性能下降: 数据库处理无效请求会消耗资源，影响正常请求的处理速度。
• 安全风险: 可能被恶意利用进行 DDoS 攻击。

解决方案:

• 缓存空值 (Cache Null Values):原理: 当数据库查询结果为空时，仍然将空值 (例如 null 或特殊标记) 缓存到 Redis 中，并设置一个较短的过期时间 (例如几秒或几分钟)。下次请求相同的 Key 时，直接从缓存中返回空值，避免穿透到数据库。实现: 判断数据库查询结果是否为空，如果为空则将空值存入 Redis。代码示例 (Java):
• java复制代码

String value = redisTemplate.opsForValue().get(key); if (value != null) { return value; }

    value = databaseService.query(key);
    if (value == null) {
        redisTemplate.opsForValue().set(key, "null", 60, TimeUnit.SECONDS); // 缓存空值，过期时间 60 秒
        return null; // 返回 null 或其他表示空值的标记
    } else {
        redisTemplate.opsForValue().set(key, value, expireTime, TimeUnit.SECONDS);
        return value;
    }
    ```
* **注意:**  空值的过期时间不宜过长，避免缓存脏数据。

• 布隆过滤器 (Bloom Filter):
• 原理: 在缓存之前设置一个布隆过滤器，将所有存在的 Key 预先加载到布隆过滤器中。当请求到达时，先通过布隆过滤器判断 Key 是否可能存在，如果布隆过滤器判断 Key 不存在，则直接返回，避免查询缓存和数据库。
• 实现: 可以使用 Redis 的布隆过滤器模块 (RedisBloom) 或其他布隆过滤器库 (如 Guava BloomFilter)。
• 优点: 高效判断 Key 是否可能存在，误判率可控。
• 缺点: 存在误判率 (False Positive)，即布隆过滤器判断 Key 存在，但实际可能不存在。不适合需要精确判断 Key 是否存在的情况。
• 输入校验 (Input Validation):
• 原理: 在请求入口处进行参数校验，过滤掉非法参数，例如 Key 的格式、类型等，防止恶意请求穿透缓存。
• 实现: 可以使用正则表达式、数据类型校验等方式进行参数校验。
• 场景: 适用于可以预知 Key 的格式和类型的情况。
• 限流 (Rate Limiting):
• 原理: 对请求进行限流，限制单位时间内请求的数量，防止恶意请求大量穿透缓存。
• 实现: 可以使用限流组件 (如 Sentinel、Guava RateLimiter) 等。
• 场景: 作为一种保护措施，防止恶意攻击。

3. 缓存击穿 (Cache Breakdown / Hotspot Key)

问题描述:

缓存击穿是指一个热点 Key (访问频率非常高的 Key) 在缓存中过期失效，导致大量请求同时穿透缓存，直接打到数据库，瞬间给数据库带来巨大的压力。与雪崩不同的是，击穿是针对单个热点 Key，而雪崩是大量 Key。

原因:

• 热点 Key 过期: 热点 Key 设置了过期时间，并在高并发访问时过期。
• 热点 Key 被手动删除: 运维人员或程序误操作删除了热点 Key。

危害:

• 数据库压力骤增: 大量请求同时访问数据库的热点数据，可能导致数据库压力过大，甚至宕机。
• 性能下降: 数据库处理大量请求会消耗资源，影响其他请求的处理速度。
• 服务不稳定: 数据库压力过大可能导致服务不稳定。

解决方案:

• 互斥锁 (Mutex) 或分布式锁 (与雪崩解决方案类似):
• 原理: 当热点 Key 缓存失效时，只允许一个请求去重建缓存，其他请求等待重建完成，避免大量请求同时穿透缓存。
• 实现: 与缓存雪崩的互斥锁方案类似，可以使用 Redis 的 SETNX 命令实现分布式锁。
• 流程:请求到达，查询缓存，如果热点 Key 缓存失效。尝试获取分布式锁 (例如 SETNX hot_key_lock value NX PX 5000)。如果获取锁成功，则从数据库加载热点数据，重建缓存，释放锁。如果获取锁失败，则等待一段时间 (例如几毫秒) 后重试查询缓存。
• “永不过期” (逻辑过期) 或设置较长的过期时间:
• 原理: 对于热点 Key，可以设置永不过期 (不设置过期时间) 或设置一个非常长的过期时间，避免热点 Key 过期导致击穿。
• 实现: 设置 Redis Key 时不设置过期时间，或者设置一个很长的过期时间。
• 数据更新: 如果热点数据需要更新，可以在后台异步更新缓存，或者使用逻辑过期的方式。
• 逻辑过期: 缓存中存储的数据除了实际值，还包含一个过期时间戳。程序在读取缓存时，判断当前时间是否超过过期时间戳，如果超过则异步更新缓存，但仍然返回旧值，保证服务可用性。
• 热点 Key 复制多份:
• 原理: 将热点 Key 复制多份，分散请求压力，降低单个 Key 的访问频率。
• 实现: 可以使用不同的 Key 前缀或后缀来区分不同的副本。
• 场景: 适用于热点 Key 的数据量不大，可以复制多份的情况。
• 本地缓存 (Local Cache) + Redis 缓存 (与雪崩解决方案类似):
• 原理: 在 Redis 缓存前增加一层本地缓存 (如 Caffeine)。热点 Key 优先从本地缓存获取，本地缓存失效时再穿透到 Redis 缓存，Redis 缓存失效时才穿透到数据库。
• 实现: 可以使用 Caffeine、Guava Cache 等本地缓存库。
• 优点: 本地缓存速度更快，可以有效缓解热点 Key 击穿带来的冲击。
• 缺点: 本地缓存容量有限，数据一致性需要考虑。

通用最佳实践:

• 监控和预警: 建立完善的缓存监控体系，监控缓存命中率、过期 Key 数量、数据库负载等指标，及时发现异常情况并预警。
• 合理的缓存策略: 根据业务场景选择合适的缓存策略，包括过期时间设置、缓存更新策略、缓存淘汰策略等。
• 压力测试: 在上线前进行充分的压力测试，模拟高并发场景，验证缓存系统的稳定性，并及时调整缓存策略和容量。
• 多级缓存架构: 考虑使用多级缓存架构，例如本地缓存 + Redis 缓存，提高缓存的性能和稳定性。
• 服务降级和限流: 作为最后的保护手段，在系统出现异常时，可以进行服务降级或限流，保证核心服务的可用性。

总结:

缓存雪崩、穿透和击穿是缓存使用中常见的问题，需要根据具体场景选择合适的解决方案。理解这些问题的原理和解决方案，可以帮助我们更好地设计和维护缓存系统，提高系统的性能和稳定性。 重要的是要结合实际业务场景，综合考虑各种方案的优缺点，选择最适合的解决方案。