当前位置：首页 > news >正文

缓存雪崩、穿透、预热、更新与降级问题与实战解决方案

news 2025/7/5 5:47:40

1. 缓存雪崩 (Cache Avalanche)

缓存雪崩指的是在某一时间段内，缓存服务器集体失效，导致大量请求直接打到数据库，数据库因无法承受巨大压力而宕机，从而引发整个系统崩溃的现象。

常见原因：

缓存过期时间集中： 大量缓存设置了相同的过期时间，在同一时刻全部失效。
缓存服务故障： 缓存服务器（如 Redis 集群）发生大规模宕机，导致所有缓存数据丢失。

解决方案：

分散缓存过期时间： 为缓存的过期时间增加随机值，避免大量缓存同时失效。例如，在原有过期时间基础上，加上一个 0 到 N 秒的随机数。

// 假设 baseExpireTime 为 3600 秒 (1小时)
long baseExpireTime = 3600;
Random random = new Random();
// 增加一个 0 到 300 秒的随机值
long finalExpireTime = baseExpireTime + random.nextInt(301); 
redisTemplate.opsForValue().set("product:123", product,finalExpireTime, TimeUnit.SECONDS
);

高可用缓存集群： 部署高可用的缓存集群（如 Redis Cluster），确保部分节点宕机时，其他节点仍能提供服务。
熔断与限流： 当数据库压力过大时，通过熔断机制暂时切断部分请求，或通过限流保护数据库不被击垮。
多级缓存： 引入多级缓存，例如本地缓存 + 分布式缓存，当分布式缓存失效时，请求可以先命中本地缓存。

2. 缓存穿透 (Cache Penetration)

缓存穿透指的是查询一个不存在的数据时，由于缓存中没有，导致每次请求都直接打到数据库，造成数据库额外压力的现象。恶意攻击者可能会利用这一点，查询大量不存在的数据来攻击系统。

常见原因：

业务逻辑错误： 查询了数据库中不存在的数据。
恶意攻击： 攻击者构造大量不存在的 Key 进行查询。

解决方案：

缓存空对象： 当查询数据库发现数据不存在时，也将这个空结果缓存起来（设置较短的过期时间），后续相同的查询会直接从缓存返回空，避免再次穿透到数据库。

String result = redisTemplate.opsForValue().get(key);
if (result != null) {if ("".equals(result)) { // 假设 "" 表示空对象return null; // 返回业务上的空}return JSON.parseObject(result, Product.class);
}Product product = productMapper.selectById(id);
if (product == null) {// 缓存空值redisTemplate.opsForValue().set(key, "", 5, TimeUnit.MINUTES);return null;
}
redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 1, TimeUnit.HOURS
);
return product;

布隆过滤器 (Bloom Filter)： 在缓存层和数据库层之间加入布隆过滤器。布隆过滤器是一个数据结构，可以快速判断某个 Key 是否存在。如果布隆过滤器判断 Key 不存在，则直接返回，避免查询缓存和数据库。

注意： 布隆过滤器存在误判率，即可能会将不存在的 Key 误判为存在，但这只会增加一次缓存查询，不会穿透到数据库。

// 伪代码：初始化布隆过滤器
BloomFilter<String> bloomFilter = BloomFilter.create(// 100万容量，1%误判率Funnels.stringFunnel(Charsets.UTF_8),1000000,0.01
);
// 从数据库加载所有商品ID并加入布隆过滤器
List<String> productIds = productMapper.getAllProductIds();
for (String id : productIds) {bloomFilter.put(id);
}// 查询逻辑
public Product getProduct(String productId) {// 布隆过滤器判断不存在if (!bloomFilter.mightContain(productId)) {return null; // 直接返回空，不查缓存和数据库}// ... 继续查询缓存和数据库逻辑 ...
}

请求参数校验： 在应用层对请求参数进行严格校验，过滤掉非法或明显不存在的请求。

3. 缓存预热 (Cache Warm-up)

缓存预热指的是在系统上线前或高峰期到来之前，提前将即将被访问的热点数据加载到缓存中，避免用户首次访问时因缓存未命中而直接查询数据库，造成瞬时压力。

常见原因：

新系统上线： 没有任何缓存数据。
缓存服务重启： 缓存数据全部丢失。
业务高峰期前： 预测到即将有大量用户访问某些数据。

解决方案：

数据预加载：

启动时加载： 在应用启动时，通过程序加载核心业务数据到缓存。

在 Spring Boot 应用中，可以使用 @EventListener(ApplicationReadyEvent.class) 或实现 CommandLineRunner 接口，在应用启动成功后执行缓存预热逻辑。

@Component
public class CacheWarmUpRunner implements CommandLineRunner {@Autowiredprivate ProductService productService; // 假设有获取商品的服务@Overridepublic void run(String... args) throws Exception {System.out.println("开始进行缓存预热...");// 加载最热门的1000个商品数据到缓存List<Product> hotProducts = productService.getTopHotProducts(1000);for (Product product : hotProducts) {// 调用服务内部的缓存写入逻辑productService.cacheProduct(product.getId(), product); }System.out.println("缓存预热完成！");}
}

定时任务加载： 定时扫描数据库或分析用户行为日志，将热点数据异步加载到缓存。
MQ 消息触发： 数据变更时，通过消息队列通知缓存服务更新或加载数据。

人工干预： 对于特别重要的热点数据，可以通过管理后台手动触发加载。
流量回放： 模拟线上真实流量，对缓存进行预热。

4. 缓存更新 (Cache Update)

缓存更新指的是当数据库中的数据发生变化时，如何保证缓存中的数据与数据库保持一致性的策略。这是缓存管理中最复杂的部分之一。

常见策略：

Cache Aside (旁路缓存模式)：

读操作： 先查询缓存，如果命中则返回；如果未命中，则查询数据库，并将结果放入缓存，再返回。

// 读操作
public Product getProductById(String productId) {String productJson = redisTemplate.opsForValue().get("product:" + productId);if (productJson != null) {return JSON.parseObject(productJson, Product.class);}Product product = productMapper.selectById(productId);if (product != null) {redisTemplate.opsForValue().set("product:" + productId, JSON.toJSONString(product), 1, TimeUnit.HOURS);}return product;
}

写操作： 先更新数据库，然后删除缓存。注意： 为什么是删除而不是更新？因为更新缓存可能会面临并发问题，如果更新缓存失败，容易导致数据不一致。删除缓存可以保证下次查询时从数据库获取最新数据。
- ```
// 写操作 (更新商品信息)
public void updateProduct(Product product) {productMapper.updateProduct(product); // 1. 更新数据库redisTemplate.delete("product:" + product.getId()); // 2. 删除缓存
}
```

Read Through (读穿透模式)：
- 读操作： 应用程序只从缓存中读取数据。如果缓存中没有，由缓存系统（例如通过配置的加载器）负责从底层数据源（如数据库）中读取数据并将其放入缓存，然后再返回给应用程序。
Write Through (写穿透模式)：
- 写操作： 应用程序只向缓存中写入数据。由缓存系统负责将数据写入底层数据源。通常用于同步写场景。
Write Back (回写模式)：
- 写操作： 应用程序将数据写入缓存，然后缓存异步地将数据写入底层数据源。这种模式性能最好，但数据一致性风险最高（数据可能在缓存中，但还没写入数据库，此时缓存服务宕机可能丢失数据）。

一致性问题与解决方案：

读写并发问题（Cache Aside）：
- 先更新数据库，再删除缓存： 如果删除缓存失败，可能导致脏数据。
- 先删除缓存，再更新数据库： 如果更新数据库失败，也会导致脏数据。
- 解决方案：
  - 重试机制： 删除缓存失败时进行重试。
  - 消息队列： 通过 MQ 异步删除缓存，确保最终一致性。数据库更新成功后发送消息，缓存服务消费消息并删除缓存。
  - 双删策略： 读缓存之前和之后各删一次，降低不一致概率。

延迟双删： 在更新数据库成功后，立即删除缓存；然后异步地，等待一段时间（如几秒），再删除一次缓存。这是 Cache Aside 模式的优化，用于解决在写操作过程中，读操作可能读取到旧数据并重新缓存的问题

public void updateProductWithDelayDelete(Product product) {// 1. 更新数据库productMapper.updateProduct(product);// 2. 第一次删除缓存redisTemplate.delete("product:" + product.getId());// 3. 异步延迟删除CompletableFuture.runAsync(() -> {try {Thread.sleep(500); // 延迟 500ms，等待可能发生的读请求// 第二次删除缓存redisTemplate.delete("product:" + product.getId());} catch (InterruptedException e) {Thread.currentThread().interrupt();}});
}

版本号或时间戳： 在数据中引入版本号或时间戳，在更新缓存时校验版本号，避免旧数据覆盖新数据。

5. 缓存降级 (Cache Degredation)

缓存降级是指当系统出现故障（如数据库压力过大、缓存服务宕机）或非核心业务对实时性要求不高时，为了保证核心服务的可用性，暂时停止使用缓存或降低缓存的使用频率，甚至直接返回默认数据或旧数据的一种保护措施。

常见原因：

数据库压力过大： 避免数据库彻底崩溃。
缓存服务故障： 确保应用仍能提供基本服务。
非核心功能异常： 允许部分功能降级，保障核心功能。

解决方案：

预设兜底数据： 在缓存失效或无法访问时，从本地文件、内存或数据库中获取预设的、可接受的旧数据或默认数据。

public Product getProductByIdSafely(String productId) {try {// 尝试从 Redis 获取String productJson = redisTemplate.opsForValue().get("product:" + productId);// 判断是否获取到了数据，if (productJson != null) {// 如果获取到了直接返回return JSON.parseObject(productJson, Product.class);}// 若没有则从数据库中获取Product product = productMapper.selectById(productId);if (product != null) {// 将其写入 Redis 缓存并设置过期时间为1小时redisTemplate.opsForValue().set("product:" + productId, JSON.toJSONString(product), 1, TimeUnit.HOURS);}return product;} catch (Exception e) {// Redis 或数据库异常，触发降级System.err.println("缓存或数据库服务异常，正在进行降级处理：" + e.getMessage());// 返回默认数据或从本地文件读取兜底数据return getDefaultProductPlaceholder(productId); }
}private Product getDefaultProductPlaceholder(String productId) {// 可以从本地文件、内存缓存或一个静态 Map 中获取Product defaultProduct = new Product();defaultProduct.setId(productId);defaultProduct.setName("商品信息加载失败");defaultProduct.setDescription("请稍后再试或联系客服。");return defaultProduct;
}