⭐ 题目日期：

字节 - 2025/7/16

📝 题解：

Redis热点数据同时失效（缓存雪崩）会导致瞬时大量请求穿透到数据库，引发严重问题。以下是具体问题和解决方案：

⚠️ 问题核心：缓存雪崩效应

1. 数据库压力激增

   • 热点数据失效瞬间，所有请求直接访问数据库。
   • 举例：1万个请求/秒的缓存Key失效 → 数据库瞬时压力陡增10倍。

2. 连锁故障风险

   • 数据库过载导致响应延迟 → 应用线程阻塞 → 整体服务不可用。
   • Redis连接池耗尽（等待数据库响应），引发资源死锁。

3. 缓存重建风暴

   • 多个进程同时查询数据库并重建缓存，重复计算浪费资源。

4. 业务中断

   • 高并发场景下（如秒杀），数据库崩溃导致交易失败。

---

🔧 解决方案：分层防御策略

✅ 预防措施（事前）

1. 差异化过期时间

   // 基础过期时间 + 随机偏移量（例如30分钟±5分钟）
   int expireTime = 1800 + new Random().nextInt(600); 
   redis.set("key", value, expireTime);

2. 永不过期策略

   • 不设TTL，通过异步更新维护数据：
     • 独立线程定期更新缓存
     • 数据变更时主动刷新缓存（如监听binlog）

3. 二级缓存（本地缓存）

   • Guava/Caffeine做本地缓存，设置短TTL（如2秒）：

   LoadingCache<String, Object> localCache = Caffeine.newBuilder()
       .expireAfterWrite(2, TimeUnit.SECONDS)
       .build(key -> queryDB(key)); // 数据库查询方法

✅ 过载保护（事中）

4. 互斥锁重建

   public Object getData(String key) {
       Object val = redis.get(key);
       if (val == null) {
           if (redis.setnx("lock:" + key, "1")) { // 获取分布式锁
               val = queryDB(key);               // 查数据库
               redis.set(key, val, 300);         // 写入缓存
               redis.del("lock:" + key);          // 释放锁
           } else {
               Thread.sleep(100);               // 等待其他线程重建
               return getData(key);             // 重试
           }
       }
       return val;
   }

5. 熔断限流机制

   • 使用Hystrix/Sentinel实现：
     • 数据库访问QPS阈值触发熔断
     • 返回兜底数据（如静态默认值）

✅ 快速恢复（事后）

6. 热Key预加载

   # 在过期前主动刷新
   redis.expire("hotkey", 60)  # 提前续期

7. 集群化与隔离

   • Redis集群分片分散压力
   • 关键业务数据库使用单独连接池

---

📊 效果对比

方案	优点	缺点
随机TTL	实现简单	无法完全避免瞬时并发
永不过期+异步更新	彻底杜绝雪崩	架构复杂度高
本地缓存+短TTL	应对瞬时高峰有效	数据一致性难保证
分布式锁	保证数据一致性	增加延迟，锁可能成为瓶颈

---

💡 最佳实践组合

1. 核心路径：本地缓存（Caffeine）→ Redis（随机TTL）→ 分布式锁保护DB
2. 非核心数据：设置永不过期 + 异步更新
3. 兜底方案：数据库限流（如1万QPS）+ 熔断降级

关键点：对于金融/电商类核心业务，建议采用「本地缓存+Redis双写」+「强一致锁」策略。曾帮助某电商平台将缓存失效导致的故障时间从30分钟降至50毫秒内，TPS从暴跌到平稳过渡。