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

在日常开发中，我们经常会在后端引入 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 后端解决方案：

加分布式锁/互斥锁：在查询数据库并重建缓存时，只允许一个线程去访问数据库，其余线程等待。常用做法是在 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);
}

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

自动续期（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分钟
    }
}

热点数据永久有效：对少数极热的数据（如即将秒杀的商品）不设置过期时间，在活动前预热缓存，活动后再清除缓存即可。这种方式虽然加大了缓存维护成本，但能彻底避免该 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一次这样就没问题了或者通过消息队列删除利用消息队列的重试机制保证数据强一致性