缓存雪崩的解决方案

最新推荐文章于 2024-10-09 21:35:46 发布

草明

最新推荐文章于 2024-10-09 21:35:46 发布

阅读量1.1k

点赞数 28

分类专栏：架构文章标签：缓存 spring java

本文链接：https://blog.csdn.net/galoiszhou/article/details/142759859

版权

架构专栏收录该内容

5 篇文章 0 订阅

订阅专栏

缓存雪崩指的是在短时间内，缓存中的大量数据同时失效，导致大量请求直接打到后端数据库或服务，造成后端负载激增甚至宕机的情况。缓存雪崩通常发生在缓存大量数据集中设置了相同或相近的过期时间、缓存服务器出现故障或重启等情况下。

缓存雪崩的影响与缓存穿透类似，但它往往是因为缓存失效后同时涌入大量请求，导致后端系统瞬时压力过大。而缓存穿透则是因为请求的数据从未被缓存，直接穿透到数据库。

缓存雪崩产生的原因

缓存集中失效：大量缓存数据设置了相同或相近的过期时间，导致失效时间相近时，大量请求在同一时间到达后端。
缓存服务器宕机或重启：缓存服务出现故障，导致所有请求无法命中缓存，直接涌入数据库。
高并发流量：在系统高并发下，如果缓存失效，所有请求都会直接打到数据库，导致数据库过载。

缓存雪崩的解决方案

1. 缓存过期时间的随机化

场景：大量缓存数据集中在相同时间点失效会导致请求集中涌入后端。
解决方案：在设置缓存过期时间时，可以为不同数据添加随机偏差值，让缓存数据的失效时间更加均匀，避免在同一时刻大量缓存同时失效。例如，如果缓存的默认过期时间为 1 小时，可以设置一个在 1 小时到 1 小时 10 分钟之间的随机过期时间。

const ttl = 3600 + Math.floor(Math.random() * 600); // 缓存时间随机在1小时到1小时10分钟之间

2. 双重缓存机制

场景：缓存失效时，所有请求直接打到后端，导致后端负载过重。
解决方案：
- 设置两个缓存层：第一层用于保存实际的缓存数据，第二层则存储短期的缓存副本。
- 当第一层缓存失效时，读取第二层副本，防止同时大量请求打到数据库，减缓后端压力。与此同时，后台可以异步更新第一层缓存的数据。

3. 请求互斥（锁机制）

场景：缓存失效时，大量并发请求涌入后台，导致重复计算或查询同一个数据。
解决方案：在缓存失效的情况下，引入分布式锁机制，让同一时间内只有一个请求能进行缓存的更新操作，其它请求等待锁释放，避免大量请求同时访问后端数据库。
- 例如，使用 Redis 的 SETNX 命令（Set if Not Exists）来实现分布式锁，确保只有一个请求能重建缓存数据。

const lockKey = "lock:cache_key";
const lockTimeout = 5000; // 锁超时时间
const isLocked = await redis.set(lockKey, "locked", "NX", "PX", lockTimeout);
if (isLocked) {
  // 只有获得锁的请求进行缓存更新操作
  const data = await fetchDataFromDB();
  await redis.set(cacheKey, data, "EX", cacheExpiration);
  await redis.del(lockKey); // 解锁
}

4. 缓存预热

场景：系统刚启动或更新时，缓存数据尚未加载，导致大量请求直接访问后端。
解决方案：在系统启动或大版本更新时，提前将常用或热点数据加载到缓存中，避免在高并发时突然失效产生大量请求。
- 例如，在系统启动时运行缓存预热脚本，将常用的数据批量加载到缓存中。

5. 服务降级

场景：当缓存失效导致后端压力过大时，系统仍然需要保持可用性。
解决方案：可以在后端系统无法处理大量请求时进行服务降级，返回一些默认数据或提示信息。
- 例如，当后端负载较高时，返回上一次缓存的数据，或者返回一个“系统繁忙，请稍后再试”的默认提示，防止系统完全不可用。

6. 多级缓存架构

场景：单个缓存层无法应对高并发请求，且缓存雪崩时，所有请求都会直接打到后端数据库。
解决方案：引入多级缓存架构，将缓存分布到多个层次，例如CDN 缓存、本地缓存、分布式缓存（如 Redis）等，使得缓存命中率最大化，减少后端压力。
- 在这种架构下，CDN 缓存作为第一层防线，减少请求打到分布式缓存系统，分布式缓存再进一步保护数据库。