苏州市天智教育培训中心_大数据_缓存穿透与击穿把数据库打挂

> 本文由 苏州市天智教育培训中心 技术团队整理，基于真实生产故障复盘，面向一线运维与开发同学，可直接用于排障参考。

一、问题现象

数据库连接数飙满、CPU 100%，而 Redis 命中率只有 20%。大量请求绕过缓存直击数据库，典型的穿透 + 击穿组合拳。

二、排查思路速览

先按下面的路径走，每一步都有明确的判断分支，避免"上来就重启"这种无效操作。

三、先看清链路：Redis 的典型架构

动手之前先明确"请求经过了哪些环节"，把问题定位到具体一层，排查效率会成倍提升。

四、根因分析

结合现场日志、监控与配置，逐条核对，绝大多数情况都能收敛到下面这几类原因：

1. 恶意或异常参数查询不存在的 ID，每次都打到数据库
2. 热点 key 过期瞬间，大量并发全部回源
3. 缓存批量过期（同一时刻写入、同一时刻过期）
4. 缓存异常后未降级，全量请求直接压到数据库

五、处置过程

处置原则：先止血、再根治。先让业务恢复，再回头解决根因，不要在故障中做长期改造。

1. 穿透：空值也缓存（短 TTL）+ 参数校验前置
2. 击穿：热点 key 加互斥锁或逻辑过期，避免同时回源
3. 雪崩：过期时间加随机抖动，避免同时失效
4. 永远给数据库留一层限流 / 熔断兜底

六、关键命令与配置

下面这些命令/配置可以直接在生产上核对（执行前请确认环境与权限）：

// 空值缓存 + 互斥锁 双保险
String key = "sku:" + id;
String v = redis.get(key);
if (v == null) {
  String lock = "lock:" + id;
  if (redis.setnx(lock, "1", 10)) {            // 只有一个线程回源
    v = db.query(id);
    redis.set(key, v == null ? "" : v, 300);   // 空值也缓存，短 TTL
    redis.del(lock);
  } else {
    Thread.sleep(50); v = redis.get(key);      // 其它线程稍等再取
  }
}

七、复盘

故障恢复后必须做复盘，重点不是"谁的责任"，而是"哪个机制缺位"：

1. 根因是有外部爬虫遍历不存在的商品 ID，每次穿透到数据库
2. 复盘确认缓存层没有"兜底空值"，也没参数白名单校验
3. 数据库没有连接数上限保护，直接被拖垮

八、预防建议

1. 缓存三件套成为标准写法：空值缓存、互斥锁、随机过期
2. 入口做参数校验与频率限制
3. 数据库侧加最大连接数与慢查询熔断
4. 监控缓存命中率，低于阈值即告警

九、官方版本动态（自动同步）

以下内容由官方发布渠道自动同步（最近同步 2026-10-11），用于提醒你：同一个问题在不同版本上的表现与处置方式可能不同，动手前先确认线上实际版本。

• Redis Release 8.10.2（2026-09-17 发布）：Redis Release 8.10.2 官方说明

• Redis Release 8.8.3（2026-09-17 发布）：Redis Release 8.8.3 官方说明

• Redis Release 8.6.7（2026-09-17 发布） 官方说明

> 版本升级前务必先在测试环境验证，特别是标注了「破坏性变更」或「停止维护」的版本。

十、写在最后

上面这套排查方法，是 Redis 在生产环境中最常见的一类问题，也是大数据方向岗位面试里经常被追问的场景题。很多人搜「苏州运维」或者关心「数据库运维培训」，真正想确认的其实是：课程讲不讲真实的线上故障。我们在云计算运维工程师课程里，会把这类故障做成实战演练——从监控曲线、日志、命令输出一路推到根因，再动手恢复，而不是背命令。苏州校区面授 + 线上同步，主打苏州运维方向的实战教学，就业推荐覆盖江浙沪。如果你正在做大数据方向、或者想转行进入大数据领域，可以了解一下我们的课程（苏州运维、数据库运维培训、苏州运维哪个好），也可以直接联系我们做一次免费的职业与技术评估。

十一、延伸阅读

• 云计算运维工程师课程大纲
• 苏州校区地址与到校路线
• 预约 0 元试学两周
• 查看全部技术排错文档