缓存击穿 缓存穿透 缓存雪崩

缓存击穿 缓存穿透 缓存雪崩

在日常开发中，我们经常会在后端引入 Redis 缓存来减轻数据库压力、提高访问性能。本文将逐点介绍 Redis 缓存常见问题及解决策略。

缓存穿透

• 问题描述： 缓存穿透指的是客户端请求的数据，在缓存中和数据库中都不存在，因此每次请求都会直接绕过缓存，打到数据库上。这样缓存“形同虚设”。如果有大量此类请求，数据库可能因承受不住压力而挂掉。

• 场景示例：

  比如购物系统中，有人恶意猜测或刷取不存在的商品 ID：用户每次请求一个在缓存和数据库都找不到的 ID。这种情况下，每次访问都要查询数据库，并发现数据不存在，无法写入缓存。如 CSDN 博客所述，“每次这个用户请求过来，都要查询一次数据库”，显然缓存不起作用，就像被穿透一样。另一种情况是业务逻辑本身产生的空查询，比如用户输入了非法参数（例如 ID 开头不符合规范），也会导致频繁请求数据库但无法命中缓存。

• 技术原理： 由于所请求的数据本来就不存在于后端存储中，所以缓存失效，所有请求都直接穿透到数据库。缓存层无法拦截这类请求，数据库压力骤增。

• Java 后端解决方案：

  1. 参数校验：对请求参数做严格校验。比如合法用户 ID 必须以 15 开头，如果检测到以 16 开头的非法 ID，就直接拒绝请求。这可以拦截掉部分恶意伪造的请求。

  2. 布隆过滤器：将数据库已有的数据预先加载到布隆过滤器中，对输入数据做快速存在性判断。只有布隆过滤器认定可能存在的请求才继续查询缓存或数据库；认定不存在的直接拒绝。布隆过滤器内存占用小、性能高，但存在一定误判率（可能误判数据存在）。实际应用中，如数据量较大（千万级以上），可用布隆过滤器避免大量不存在的数据请求打到数据库。

  3. 缓存空值：如果查询数据库后发现数据不存在，也在缓存中写一个空值（或特殊标记）并设置短过期时间。后续相同请求直接命中这个空值，避免重复访问数据库。正如博文所示：“当某个用户 id 在缓存中查不到，在数据库中也查不到时，也需要将该用户 id 缓存起来，只不过值是空的”，这样下次相同请求就从缓存拿到空数据，不再访问数据库。实现示例代码：

     String cacheKey = "user:" + id;
     String value = jedis.get(cacheKey);
     if (value == null) {User user = database.queryUserById(id);  // 查询数据库if (user != null) {jedis.set(cacheKey, toJson(user), "PX", 30000); // 正常缓存 30s} else {jedis.set(cacheKey, "", "PX", 5000); // 缓存空值，过期短一点}return user;
     }
     // value 可能是空字符串，直接返回 null 或处理为空情况
     return value.isEmpty() ? null : fromJson(value);
     

     以上方案实现简单、开销较低，但要注意空值占用缓存空间和适当设置过期时间。

• 注意事项：

  • 缓存空值虽然简单，但会消耗额外的内存，且短时间内会造成一定的不一致（数据库更新后缓存空值仍然存在）。一般将空值过期时间设置得较短，定期清除。
  • 布隆过滤器能有效减少数据库访问，但需要定期同步数据并承担误判的风险。布隆过滤器是空间换时间的方案，可用于海量数据环境。

缓存击穿

• 问题描述： 缓存击穿（又称热点 Key 问题）指的是某一个热门数据的缓存失效，在高并发下大量请求同时落到数据库。例如秒杀期间，某个热门商品的缓存正好过期，大量用户同时请求该商品信息，导致所有请求绕过缓存并发打到数据库上，数据库瞬时压力骤增，可能宕机。

• 场景示例：

  比如电商系统举办促销活动，一件热门商品的详情被频繁浏览。为了加速响应，这件商品的信息通常会被缓存。但如果缓存 TTL 到期失效且没有及时预热，活动期间数千、上万并发请求会在同一时间查询数据库 如果有大量的用户请求同一个商品，但该商品在缓存中失效了，一下子这些用户请求都直接怼到数据库，可能会造成瞬间数据库压力过大，而直接挂掉。

• 技术原理： 单个热点 key 失效导致数据库瞬时承受洪峰式的压力。数据库的吞吐量远低于缓存，如果没有保护措施，容易被击垮。

• Java 后端解决方案：

  1. 加分布式锁/互斥锁：在查询数据库并重建缓存时，只允许一个线程去访问数据库，其余线程等待。常用做法是在 Redis 上使用 SETNX 加锁，伪代码如下：

     java
     复制编辑
     String lockKey = "lock:product:" + productId;
     String requestId = UUID.randomUUID().toString();
     // 尝试加锁，设置超时时间
     String result = jedis.set(lockKey, requestId, "NX", "PX", 5000);
     if ("OK".equals(result)) {// 获得锁，查询数据库并重建缓存Product prod = database.queryProductById(productId);jedis.set("product:" + productId, toJson(prod), "PX", 60000);// 释放锁if (requestId.equals(jedis.get(lockKey))) {jedis.del(lockKey);}return prod;
     } else {// 没获得锁的线程可以自旋或休眠后重试Thread.sleep(50);return getProductById(productId);
     }

     这样只有拿到锁的线程会查询数据库并写缓存，其它并发线程等待缓存更新后直接读取缓存。

  2. 自动续期（Cache 预刷新）：定时任务定期访问热点数据或延长其过期时间，确保缓存持续有效，避免过期。比如设置商品缓存 30 分钟过期，但每隔 20 分钟就执行一次刷新操作，重新写入缓存并续期。

     // 定时任务
     @Scheduled(cron = "0 0/20 * * * ?")
     public void refreshHotProducts() {List<Integer> hotIds = getHotProductIds();for (int id : hotIds) {Product prod = database.queryProductById(id);jedis.set("product:" + id, toJson(prod), "PX", 1800000); // 30分钟}
     }
     

  3. 热点数据永久有效：对少数极热的数据（如即将秒杀的商品）不设置过期时间，在活动前预热缓存，活动后再清除缓存即可。这种方式虽然加大了缓存维护成本，但能彻底避免该 Key 过期带来的击穿风险。

• 注意事项：

  • 分布式加锁需要考虑锁释放的安全性（如使用 UUID 进行比对防止误删他人锁）。
  • 自动续期在某些场景下会增加写负担，要根据实际业务决定是否适用。
  • 对活动热度可预估的场景，预热缓存 是最有效的策略：活动开始前把热门数据全拉取到缓存，活动结束后再删除缓存。

缓存雪崩

• 问题描述： 缓存雪崩是缓存击穿的“高级版”，指在某一时间窗口内大量缓存同时失效或者缓存服务故障，导致大量请求同时穿透到数据库，产生巨大冲击。它的两种典型形式是：

  • 批量失效型： 数量众多的缓存键同时到期。
  • 服务故障型： Redis 集群或主节点宕机。

  在这两种情况下，都有大量请求透过缓存层访问数据库，数据库面临成倍的负载压力。

• 场景示例：

  1. 缓存集体过期：例如系统缓存设置统一过期时间，到了凌晨1点很多 key 同时过期，半夜也会有流量，小流量用户访问大量未命中缓存的热点数据造成数据库压力尖峰。
  2. Redis 故障：假设 Redis 节点因为硬件故障或网络问题离线，整个缓存池不可用，所有读请求都落到数据库。

  “商品表几百万条数据已预热到 Redis 并设置了过期时间，结果某天凌晨全部过期，大量用户同时访问数据库，压力剧增”。

• 技术原理： 缓存失效行为在短时间内剧增，导致数据库瞬时接收远超常态的请求量。Redis 服务不可用则同理，读缓存失败后落到数据库的量级成倍增长。

• Java 后端解决方案：

  1. 设置过期时间加随机数：在设置缓存过期时间时增加一点随机值，避免所有 Key 在同一时刻到期。比如原本 TTL 是 30 分钟，可以写成 实际过期 = 30 分钟 + random(0~60秒)。简单示例：

     int baseExpire = 1800; // 30 分钟
     int randomSec = new Random().nextInt(60); // 0~59秒随机
     jedis.expire(key, baseExpire + randomSec);
     

     这样即使高并发下大量请求同时缓存，过期时间也会错开，减少瞬时失效量。

  2. 保证高可用架构：避免 Redis 单点故障。例如使用 Redis 哨兵（Sentinel）或集群模式，确保某个实例挂掉时自动进行主从切换或分片容错，防止整个缓存服务不可用。举例：部署多个 Redis 主从节点、搭建哨兵集群，当某个 Master 挂掉时，Sentinel 会自动选举新的 Master，保持缓存服务可用。

  3. 服务降级（熔断）：当发现 Redis 不可用或请求过多时，可临时降级到备用方案（例如返回静态兜底数据或提示系统维护），降低数据库压力。具体可以设置一个全局开关：如果单位时间内缓存请求失败超限（例如1分钟内失败超过10次），开启降级策略，用户请求直接返回默认值或提示。后台可通过定时任务监控缓存恢复情况，条件满足时关闭降级，恢复正常服务。

• 注意事项：

  • 随机过期只能降低同时失效的概率，不能完全避免；故常配合高可用方案使用。
  • 服务降级涉及业务逻辑设计，应根据实际场景谨慎选择。某些场景下返回“默认数据”可能会引起业务误解，需要额外评估风险。
  • 监控 Redis 内存和连接数，提前发现瓶颈，避免无预警的大量缓存过期。

数据不一致

• 问题描述： 数据库和缓存的双写一致性问题是经典缓存应用难点。在高并发场景下，缓存和数据库之间可能出现读写错序、更新丢失等问题，导致数据库和缓存中的数据不同步，引发数据不一致现象。
• 场景示例：现在你在开发一个电商秒杀模块 对于这种商品数量实时变化的信息 则要保证数据的强一致性 因此你决定当数据库发生变化时 让缓存也更新 非常直观 但上线后发现 数据会出现不一致性 原因是大家疯狂下单 服务器的多个线程就会同时访问 而多线程之间会有时序错乱的问题 所以用户看到的数据和你数据库实际数据不同 后来你们决定用先更新数据库 在删除缓存 但这会出现删除时大量读数据打到mysql上导致MySQL崩溃了 发生了缓存击穿 解决方法也很简单 也就是加上互斥锁 但同时还有一个小问题 当删除缓存的时候 redis中数据同时过期了 此时另一个线程也来读数据 也就会将旧数据写入redis 这样我们就可以用延时双删 也就是先删redis 在更新MySQL 再删除redis一次 这样就没问题了或者通过消息队列删除 利用消息队列的重试机制保证数据强一致性