缓存穿透是后端开发中最经典也最容易引发事故的问题之一。它的特征很直接请求一直在查询一个不存在的数据缓存永远无法命中所有查询压力全部落到数据库上。平时流量不高看不出问题一旦遇到恶意刷接口、爬虫扫描或者大量自然请求命中不存在的 key数据库连接池会迅速被打满接口开始超时最终影响所有依赖这个数据库的业务。要防住这种问题核心思想可以理解为“给数据库请几个不同岗位的保安”入口参数校验负责拦掉明显非法的请求布隆过滤器负责判断 key 是否可能存在缓存空值负责把“查不到”的结果也存下来限流降级则负责在极端流量下保住数据库的最后底线。这四层手段可以单独使用也可以组合使用大多数生产环境通常采用两到三层的组合方案。这篇内容会从故障模型开始把缓存穿透的成因、演进路径讲清楚然后逐层讲解四类防护方案的实现思路和 Java 代码示例最后对比选型、说明性能观察方法并给出一份常见问题排查清单。适合正在做后端开发、准备数据库面试或者想加固现有缓存体系的人阅读。文中的代码基于 Spring Boot Redis 的常见写法也可以迁移到 Go、Python 或者其他 Redis 客户端实现中。先说明一个适用范围问题缓存穿透和底层数据库选型没有直接关系。无论你用的是 MySQL、PostgreSQL还是达梦数据库、Oracle只要业务逻辑是“缓存未命中就去查库”穿透风险就存在。下面所有方案都适用于这类关系型数据库场景。1. 核心能力速览一套完整的缓存穿透防护方案能力项说明解决问题大量不存在的数据请求绕过缓存直接打到数据库典型后果数据库连接池打满、接口超时、服务雪崩防护层次参数校验、布隆过滤器、缓存空值、限流降级、多级缓存兜底依赖组件Redis、应用本地内存Caffeine、数据库连接池适配数据库MySQL、PostgreSQL、达梦数据库、Oracle、Doris 等实现语言Java 示例可迁移到 Go / Python / C对业务侵入性低主要在查询入口和数据写入层做改动上线前检查项缓存命中率、数据库 QPS、内存占用、误判率这套方案不是某个开源框架而是可落地的工程实践组合。每一层有各自的作用也有各自的成本。下面先从“什么是缓存穿透”开始把问题模型建立起来。2. 缓存穿透、缓存击穿、缓存雪崩三个关键概念别搞混很多文章把这几个问题混在一起讲但实际它们是三种不同的故障需要不同的防护手段。2.1 缓存穿透缓存穿透指查询一个数据库和缓存中都不存在的数据。例如用户表里没有userId 9527这条记录但请求不断携带这个 id 访问接口。由于缓存中没有数据每次请求都会穿透缓存去查询数据库而数据库也查不到结果因此不会把结果回写缓存下一次相同请求仍然打到数据库。穿透的本质是请求对应的 key 是真实不存在的导致各个缓存层完全没有命中机会。2.2 缓存击穿缓存击穿指某个热点 key 在缓存过期的瞬间大量并发请求同时发现缓存没命中于是同时去数据库查询。和穿透的区别在于击穿的对象是存在但恰好过期的 key穿透的对象是根本不存在的 key。2.3 缓存雪崩缓存雪崩指大量 key 在同一时间段集中过期或者缓存节点宕机导致大量请求在短时间内涌入数据库。它更像一种大规模、系统级的故障解决思路通常是过期时间加随机值、缓存高可用、限流熔断等。2.4 快速对比问题针对数据触发条件核心防护缓存穿透不存在的 key持续请求不存在的数据缓存空值、布隆过滤器、参数校验缓存击穿单个热点 key热点 key 恰好过期互斥锁、逻辑过期、永不过期缓存雪崩大量 key集中过期或缓存宕机过期时间随机化、缓存集群、限流本文重点讲缓存穿透。但实际项目中击穿和雪崩的防护手段也需要一并考虑因为它们经常同时出现。3. 缓存穿透的典型场景与故障演进3.1 什么请求会打穿缓存最常见的场景有三类。第一类恶意攻击或扫描。攻击者遍历接口参数批量请求不存在的 ID、手机号、订单号。这种请求通常是自动化脚本QPS 可以拉得很高。第二类业务数据本身不存在。比如用户在前端发起了一个查询但后端对应的记录因为未上线、已删除、权限不足等原因查不到。当一个功能刚上线、历史数据还没迁移完成时这种情况最明显。第三类参数格式问题。调用方传入了非法格式的 ID例如把字符串拼进数值型主键字段底层查询自然永远查不到结果。3.2 故障演进路径只要线上存在上面任意一类场景故障演进是有固定路径的少量穿透请求到达应用层缓存未命中应用去查数据库。穿透请求量持续增加数据库连接池中的连接开始不够用。正常业务的数据库查询也需要等待连接接口响应时间拉长。上层服务开始超时重试重试又带来更多请求形成恶性循环。如果数据库没有做好连接数和 CPU 保护数据库实例可能直接进入高负载状态最终导致整条业务链路不可用。3.3 用数字感受一下压力假设数据库单机最多能扛 5000 QPS 的简单查询如果穿透请求打到 2 万 QPS即使正常业务只需要几百 QPS数据库也会被这 2 万无效查询压垮。穿透请求的成本极低但数据库处理一个无效查询的成本和有效查询几乎一样这才是最棘手的地方。4. 适用场景与使用边界4.1 适合用什么场景基于主键 ID 查询详情的接口例如用户详情、订单详情、商品详情。外部开放接口或容易被脚本刷的接口。缓存命中率偏低的业务例如数据冷热不均衡的系统。新系统上线初期大量 key 尚未被预热空查询比例较高。4.2 不适合什么场景写入频繁且几乎不读的数据没有必要做缓存防护做了反而增加一致性问题。数据库查询本身极快且压力不大的内部接口加防护层反而浪费资源。key 数量极大且生命周期极短的数据比如实时日志流布隆过滤器维护成本太高。4.3 合规与安全边界需要特别提醒在设计防护方案时涉及用户 ID、手机号、订单号等敏感数据日志和监控中不要记录完整的业务数据。做恶意请求拦截时需要基于真实业务规则判断不能因为某个用户触发多次空查询就直接封禁账号要在保护系统的同时避免误伤正常用户。生产环境做压测前必须先申请测试账号和测试链路避免对线上数据库造成次生故障。5. 防护方案一缓存空值成本最低的一层保安5.1 核心思路数据库查不到数据时不要直接返回 null而是把一个特殊标记写入缓存并设置较短的过期时间。这样后续相同请求在 TTL 内直接命中缓存看到标记后直接返回空结果不再查数据库。缓存空值方案适合大多数业务实现简单不需要引入额外组件。它的缺点是每个不存在的 key 都会占据一份 Redis 内存如果攻击者用随机 ID 不停构造请求缓存中会出现大量无效 key反而带来内存压力。因此空值的 TTL 必须比正常数据短很多。5.2 Java 实现示例public class CachePenetrationGuard { private final StringRedisTemplate redisTemplate; private final UserMapper userMapper; private static final String EMPTY_FLAG EMPTY; // 正常数据缓存 10 分钟 private static final long NORMAL_TTL_MINUTES 10; // 空值缓存只放 2 分钟避免大量空 key 堆积 private static final long EMPTY_TTL_MINUTES 2; public UserVO getUserById(String userId) { String cacheKey user:detail: userId; // 第一步查缓存 String cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { // 命中空值标记直接返回 null不查数据库 if (EMPTY_FLAG.equals(cached)) { return null; } return JSON.parseObject(cached, UserVO.class); } // 第二步缓存未命中查数据库 UserVO user userMapper.selectById(userId); if (user ! null) { redisTemplate.opsForValue().set( cacheKey, JSON.toJSONString(user), NORMAL_TTL_MINUTES, TimeUnit.MINUTES); } else { redisTemplate.opsForValue().set( cacheKey, EMPTY_FLAG, EMPTY_TTL_MINUTES, TimeUnit.MINUTES); } return user; } }5.3 注意事项空值标记要能和正常数据区分开。建议用一个业务中不会出现的字符串例如EMPTY或者用一个包装对象保存类型字段避免误把空值当真实数据解析。空值 TTL 不能太长。一般设置 1 到 5 分钟。如果数据被创建后用户立刻需要能看到TTL 过长会导致短时间数据不一致。如果业务对一致性要求较高可以缩到 30 秒左右。当数据库写入新数据时主动删除对应的空值缓存可以缩短不一致时间。在新增用户、创建订单等写入逻辑里执行完数据库写入后直接删除缓存 key下一轮查询自然读到新值。5.4 优点与局限这个方案的优点是实现成本低、立竿见影不用引入新的中间件。局限是只能拦截“已经出现过一次”的 key如果攻击者每次都用全新随机 ID缓存空值就没有命中机会内存还可能被打满。因此缓存空值适合配合下面几种方案一起用。6. 防护方案二布隆过滤器入口处先拦一道6.1 原理解析布隆过滤器是一个位数组加多个哈希函数构成的数据结构。添加元素时把元素经过 k 个哈希函数映射到位数组的 k 个位置并把对应位置置为 1。判断元素是否存在时如果所有映射位置都是 1则元素可能存在如果任意一个位置是 0则元素一定不存在。布隆过滤器有两个核心特点判断“不存在”是绝对准确的。判断“存在”有一定概率误判也就是把不存在的元素误判为存在。这个特点正好适合缓存穿透防护查询前先用布隆过滤器判断 key 是否存在如果过滤器说“一定不存在”直接返回空结果只有过滤器说“可能存在”时才允许进入后续缓存和数据库查询逻辑。6.2 应用内布隆过滤器实现在单机应用或数据量可控的场景可以使用 Guava 提供的BloomFilter。Component public class UserBloomFilter { private final BloomFilterLong userIdFilter; public UserBloomFilter() { // 预计插入 100 万个用户 ID误判率设为 1% userIdFilter BloomFilter.create( Funnels.longFunnel(), 1_000_000L, 0.01); } PostConstruct public void init() { ListLong userIds userMapper.selectAllIds(); userIds.forEach(userIdFilter::put); System.out.println(布隆过滤器初始化完成加载 ID 数量 userIds.size()); } public boolean mightExist(Long userId) { return userIdFilter.mightContain(userId); } }查询服务在查缓存前先调用mightExist方法public UserVO getUserById(Long userId) { if (!userBloomFilter.mightExist(userId)) { // 布隆过滤器判断一定不存在直接返回 return null; } // 再走缓存和数据库查询 return doQuery(userId); }这个方案能挡住绝大多数不存在的 key 的请求因为过滤器对“一定不存在”的判断不会出错。只有那些被误判为存在的 key 会继续向下传递这部分请求再交给缓存空值方案去拦截。6.3 分布式场景与 Redis 布隆过滤器单机 Guava 布隆过滤器在应用重启后会丢失数据需要重新加载全量 ID。如果应用是多实例部署每个实例都要维护一份数据一致性很难保证。这时更推荐使用 Redis 布隆过滤器。第一种方式是使用 Redis 4.0 提供的BF.ADD、BF.EXISTS命令需要 Redis 加载布隆过滤器模块。第二种方式是使用 Redisson 等客户端提供的分布式布隆过滤器RBloomFilterLong bloomFilter redisson.getBloomFilter(user-id-bloom); // 初始化预计元素数量 100 万误判率 1% bloomFilter.tryInit(1_000_000L, 0.01); // 启动时加载已有 ID ListLong userIds userMapper.selectAllIds(); userIds.forEach(bloomFilter::add); // 查询时判断 boolean exists bloomFilter.contains(userId);Redisson 会把位数组存储在 Redis 中多个应用实例共享同一个过滤器重启应用后不需要重新加载全量数据。6.4 使用布隆过滤器要注意的问题第一个问题是删除操作。布隆过滤器不支持删除单个元素。如果一个业务 ID 被删除后不再有效它仍然会被过滤器判断为可能存在多出的请求会继续往下走。解决办法是定期重建过滤器或者在关键删除操作后触发全量重建。第二个问题是初始化成本。全量加载数据库 ID 到布隆过滤器时如果数据量很大启动过程会比较慢。可以选择在低峰期做异步初始化或者用批量管道写入 Redis。第三个问题是误判率。误判率越低需要的位数组空间越大。通常设置 0.01 到 0.001 已经足够。数据量增长后原过滤器容量不足误判率会上升需要基于实际数据量重新评估容量。7. 防护方案三参数校验、限流与降级缓存空值和布隆过滤器主要解决“key 不存在”的穿透问题。但有时候请求本身就不该进入查询链路或者流量已经高到超出系统承受能力这时需要更前置的拦截手段。7.1 参数合法性校验第一层拦截是参数校验。很多穿透请求是参数本身就不合法比如主键 ID 应为正整数却传入了负数或 0。ID 应为定长字符串却传入了超长字符串。用户手机号应为 11 位却传入了字母组合。这些请求可以在 Controller 层直接拦截返回参数错误完全不需要进入查询逻辑。GetMapping(/user/{userId}) public ResultUserVO getUserById(PathVariable Long userId) { // 参数校验ID 必须为正整数且不超过业务上限 if (userId null || userId 0 || userId 100_000_000L) { return Result.error(非法用户 ID); } // 后续缓存和数据库查询 UserVO user userService.getById(userId); return Result.ok(user); }参数校验不能只做前后端联动校验后端服务必须独立校验。尤其是在开放接口场景下调用方可能完全绕过前端页面直接发 HTTP 请求。后端校验是最后一道参数防线。7.2 限流限流的核心目标是控制“进入查询链路”的请求速率。即使前面几层都没拦住限流也能保证数据库的 QPS 不会超过安全阈值。常用的限流方案有三种单机限流使用 Guava RateLimiter 或 Semaphore 限制单实例的并发查询数。分布式限流使用 Redis Lua 脚本实现令牌桶或滑动窗口算法。网关/Sentinel 限流在流量进入应用前统一拦截。以 Sentinel 为例可以在查询接口上配置 QPS 限流规则# Sentinel 限流规则配置示意 # 资源名/user/{userId} # 阈值单机 QPS 500 # 流控效果快速失败被限流的请求直接返回“系统繁忙请稍后重试”不再向下传递。限流是最后的保护伞它可以牺牲一部分请求但不让数据库被打垮。7.3 熔断与降级当数据库或下游服务的错误率升高时需要触发熔断。熔断打开后后续请求在短时间内直接走降级逻辑不调用数据库。降级策略可以是返回默认数据、返回历史缓存快照或者直接返回一个可读的错误提示。在缓存穿透防护中熔断降级尤其重要。如果数据库已经被异常流量打到高负载继续让所有请求进入查询链路只会加速崩溃。通过熔断降低对数据库的调用频率给数据库留出恢复时间。8. 防护方案四热点数据多级缓存与兜底布隆过滤器和缓存空值可以拦截大部分穿透但面对超高并发时应用层到 Redis 的连接也是资源。如果同一个热点 key 被大量请求同时命中Redis 虽然能扛住应用线程和网络带宽也有压力。更合理的方式是把热点数据再做一层本地缓存。8.1 本地缓存兜底应用本地缓存可以使用 Caffeine 或 Guava Cache放在 Redis 之前。查询流程变成查本地缓存命中则直接返回。本地缓存未命中查 Redis。Redis 未命中查数据库。数据库结果回写 Redis本地缓存也保存一份。本地缓存放在应用进程内查询不走网络性能极好。但由于每个实例各自保存一份数据一致性最弱。它适合读多写少、一致性要求不高的热点数据例如商品详情、用户昵称、配置项等。8.2 数据库连接池保护防护方案再完善也不可能做到 100% 拦截所有无效请求。数据库连接池本身的参数配置也需要调整。连接池的maximum-pool-size不宜设置过大否则数据库线程数被拉高操作系统上下文切换成本暴涨整体吞吐反而下降。合理设置等待队列长度让超出能力的请求快速失败而不是无限排队等待。以 HikariCP 为例常见的合理配置思路是spring: datasource: hikari: # 最大连接数按数据库实例规格估算 maximum-pool-size: 20 # 连接最大空闲时间 idle-timeout: 600000 # 获取连接的超时时间超过则快速失败 connection-timeout: 2000这些参数没有固定标准需要结合数据库规格、业务 QPS 和慢查询情况调整。核心原则是宁可快速失败不要让所有请求堆积在连接池等待队列里。9. 四种方案对比与选型建议方案实现成本内存/资源成本误判或副作用适用场景缓存空值最低每个空 key 占一份缓存空 key 过多会占内存空查询量不大、key 可枚举布隆过滤器中等位数组占用固定内存判断存在有误判率key 全量可加载、删除不频繁参数校验 限流 降级中低几乎无额外内存限流可能误伤正常请求开放接口、高并发入口多级缓存兜底中高增加本地内存占用数据一致性弱热点数据读多写少实际项目很少只用一个方案。最常见的组合是参数校验 缓存空值这是最基本的配置任何查询类接口都应该做。数据量可控且 ID 有规律的业务再叠加布隆过滤器。高并发且容易被脚本刷的开放接口再加上限流和熔断降级。热点数据访问频繁时再加本地缓存。从成本角度考虑建议按顺序逐步加先做参数校验和缓存空值观察缓存命中率如果数据库压力依然高再加布隆过滤器如果还存在超预期流量再上限流。不要一上来就全上每一层都有维护成本。10. 部署效果与性能观察上线防护方案后不能只看功能正常还要量化验证效果。10.1 观察缓存命中率缓存命中率是判断穿透防护是否有效的核心指标。在 Redis 中可以使用INFO stats命令查看keyspace_hits: 98000 keyspace_misses: 2000命中率 keyspace_hits / (keyspace_hits keyspace_misses)。正常情况下缓存命中率越高说明数据库查询次数越少。如果一个业务接口的缓存命中率长期低于 80%就需要检查是否有大量无效 key 在穿透。在业务层也可以埋点统计进入查询接口的总请求数、实际查询数据库的次数、命中空值缓存的次数分别打点上报到监控系统。10.2 确认数据库压力下降数据库侧的观察指标包括数据库 QPS压在 MySQL 或达梦数据库、Oracle 上的查询量是否下降。数据库连接数通过连接池监控查看活跃连接数是否趋于平稳。慢查询数量是否存在大量重复的无效查询语句。CPU 使用率数据库实例 CPU 是否回到正常水位。上线前先在测试环境压测模拟一批不存在的 key 请求对比加防护前后的数据库 QPS 和接口响应时间。上线后不要立刻做全量切换可以先放 5% 流量观察指标确认数据库侧压力明显下降后再逐步放量。10.3 内存占用变化缓存空值方案会新增 Redis 内存占用布隆过滤器的位数组也会占用一定空间。上线前要预估内存变化空值缓存按条数估算每条大约几十字节乘以 TTL 时间窗内的空 key 数量。布隆过滤器按公式计算位数组长度或者直接根据误判率和预估元素数调整tryInit参数。如果发现 Redis 内存增长过快优先检查空值 TTL 是否过长或者布隆过滤器误判率是否设置过严导致位数组过大。10.4 压测建议压测时使用 JMeter 或其他压测工具分别测三组场景正常存在的 key 请求观察基线 QPS 和响应时间。不存在的随机 key 请求观察数据库 QPS 是否暴涨。混合场景70% 正常 key 加 30% 随机不存在 key观察开启防护前后的性能差异。压测环境要与生产环境的数据库规格、网络延迟尽量保持一致否则压测结果只能作为参考不能直接推导线上容量。11. 常见问题与排查方法问题现象可能原因排查方式解决方案加了缓存空值后内存涨得很快空 key TTL 太长随机 key 太多查看 Redis key 数量和内存占用缩短空值 TTL增加布隆过滤器前置拦截布隆过滤器拦截后正常数据也查不到ID 未正确加载到过滤器检查启动初始化日志确认数据量重建过滤器使用增量加载脚本布隆过滤器误判率高数据量超过预估容量位数组太小查看过滤器容量和误判率参数扩容位数组重新初始化限流把正常流量也限掉了阈值设置过小或限流规则作用域过大查看限流日志和监控曲线调大阈值按接口拆分限流规则数据库 QPS 仍然很高防护层未覆盖所有查询入口检查是否有其他代码路径绕过缓存直接查库统一走缓存查询入口禁止散落查询代码缓存空值导致数据不一致数据更新后空值缓存未删除数据写入时是否执行了删除缓存操作写入逻辑中主动删除旧 key缩短空值 TTL重启应用后布隆过滤器失效使用应用内 Guava 过滤器数据未持久化检查重启后的命中情况改用 Redis 布隆过滤器或启动时全量重建Redis 连接数过多加了布隆过滤器但 Redis 连接池配置过小查看 Redis 客户端连接数调大连接池或对热点 key 增加本地缓存排查时建议从一条完整请求链路开始请求进入应用后是否先过参数校验再过布隆过滤器再查本地缓存再查 Redis最后才到数据库。每一个环节打印一条轻量日志记录命中状态就能快速定位是哪一层没有拦住。12. 最佳实践与合规提醒12.1 工程实践建议第一防护方案要统一封装不要散落在业务代码里。建议做一个公共方法比如getWithBloomFilterAndEmptyCache业务代码只调用一个方法内部完成布隆过滤器判断、缓存查询、空值写入的逻辑。这样新接入的业务不需要重新理解整套流程也不容易漏掉某一层防护。第二空值缓存和正常缓存的 key 命名要能区分。建议使用不同的前缀例如empty:user:detail:9527和user:detail:9527方便排查问题时快速识别。第三布隆过滤器需要定期维护。业务数据量增长时原过滤器容量可能不足。建议在数据量增长到预估值的 80% 时准备重建过滤器。第四监控告警要覆盖关键指标。至少要配置以下告警缓存命中率低于阈值。数据库活跃连接数超过连接池上限的 70%。接口响应时间 P99 超过业务 SLA。Redis 内存占用超过实例容量的 70%。第五不要在代码和日志中记录完整用户 ID、手机号等敏感信息。排查问题需要关联请求时可以使用脱敏后的标识。12.2 合规与安全使用边界在设计拦截和限流规则时要基于业务合理性不能因为用户触发了空查询就永久拉黑用户。拉黑账号、限制访问等功能涉及用户权益必须有明确的业务规则和管理流程。如果系统面向外部开放 API还需要做好调用方身份认证和配额管理。每个调用方分配独立的 AppKey 和配额单调用方超量时只对该调用方限流不影响其他正常调用方。这样即使有恶意调用方在刷不存在的 key影响范围也能被控制在最小单元。涉及商业数据、用户个人信息时缓存中的数据同样需要遵循权限管理和加密要求。存储用户缓存信息时按业务需要设置合理的 TTL避免敏感数据长时间滞留缓存层。13. 总结缓存穿透是数据库最常见的人为灾害之一但它的防护手段并不复杂。优先级建议从低到高先把参数校验做扎实再上缓存空值数据量大之后加布隆过滤器最后用限流熔断兜底。任何方案都要以数据说话。上线前在测试环境压测三组场景上线后盯住缓存命中率、数据库 QPS、Redis 内存三个指标。穿透请求拦截得干净数据库压力自然就下来了。如果现在项目里还没有任何穿透防护建议先从缓存空值开始动手这是成本最低、见效最快的一步。写完代码后别忘了补上监控指标否则下次故障来了你可能都不知道是哪一层被穿透的。
缓存穿透是后端开发中最经典也最容易引发事故的问题之一。它的特征很直接请求一直在查询一个不存在的数据缓存永远无法命中所有查询压力全部落到数据库上。平时流量不高看不出问题一旦遇到恶意刷接口、爬虫扫描或者大量自然请求命中不存在的 key数据库连接池会迅速被打满接口开始超时最终影响所有依赖这个数据库的业务。要防住这种问题核心思想可以理解为“给数据库请几个不同岗位的保安”入口参数校验负责拦掉明显非法的请求布隆过滤器负责判断 key 是否可能存在缓存空值负责把“查不到”的结果也存下来限流降级则负责在极端流量下保住数据库的最后底线。这四层手段可以单独使用也可以组合使用大多数生产环境通常采用两到三层的组合方案。这篇内容会从故障模型开始把缓存穿透的成因、演进路径讲清楚然后逐层讲解四类防护方案的实现思路和 Java 代码示例最后对比选型、说明性能观察方法并给出一份常见问题排查清单。适合正在做后端开发、准备数据库面试或者想加固现有缓存体系的人阅读。文中的代码基于 Spring Boot Redis 的常见写法也可以迁移到 Go、Python 或者其他 Redis 客户端实现中。先说明一个适用范围问题缓存穿透和底层数据库选型没有直接关系。无论你用的是 MySQL、PostgreSQL还是达梦数据库、Oracle只要业务逻辑是“缓存未命中就去查库”穿透风险就存在。下面所有方案都适用于这类关系型数据库场景。1. 核心能力速览一套完整的缓存穿透防护方案能力项说明解决问题大量不存在的数据请求绕过缓存直接打到数据库典型后果数据库连接池打满、接口超时、服务雪崩防护层次参数校验、布隆过滤器、缓存空值、限流降级、多级缓存兜底依赖组件Redis、应用本地内存Caffeine、数据库连接池适配数据库MySQL、PostgreSQL、达梦数据库、Oracle、Doris 等实现语言Java 示例可迁移到 Go / Python / C对业务侵入性低主要在查询入口和数据写入层做改动上线前检查项缓存命中率、数据库 QPS、内存占用、误判率这套方案不是某个开源框架而是可落地的工程实践组合。每一层有各自的作用也有各自的成本。下面先从“什么是缓存穿透”开始把问题模型建立起来。2. 缓存穿透、缓存击穿、缓存雪崩三个关键概念别搞混很多文章把这几个问题混在一起讲但实际它们是三种不同的故障需要不同的防护手段。2.1 缓存穿透缓存穿透指查询一个数据库和缓存中都不存在的数据。例如用户表里没有userId 9527这条记录但请求不断携带这个 id 访问接口。由于缓存中没有数据每次请求都会穿透缓存去查询数据库而数据库也查不到结果因此不会把结果回写缓存下一次相同请求仍然打到数据库。穿透的本质是请求对应的 key 是真实不存在的导致各个缓存层完全没有命中机会。2.2 缓存击穿缓存击穿指某个热点 key 在缓存过期的瞬间大量并发请求同时发现缓存没命中于是同时去数据库查询。和穿透的区别在于击穿的对象是存在但恰好过期的 key穿透的对象是根本不存在的 key。2.3 缓存雪崩缓存雪崩指大量 key 在同一时间段集中过期或者缓存节点宕机导致大量请求在短时间内涌入数据库。它更像一种大规模、系统级的故障解决思路通常是过期时间加随机值、缓存高可用、限流熔断等。2.4 快速对比问题针对数据触发条件核心防护缓存穿透不存在的 key持续请求不存在的数据缓存空值、布隆过滤器、参数校验缓存击穿单个热点 key热点 key 恰好过期互斥锁、逻辑过期、永不过期缓存雪崩大量 key集中过期或缓存宕机过期时间随机化、缓存集群、限流本文重点讲缓存穿透。但实际项目中击穿和雪崩的防护手段也需要一并考虑因为它们经常同时出现。3. 缓存穿透的典型场景与故障演进3.1 什么请求会打穿缓存最常见的场景有三类。第一类恶意攻击或扫描。攻击者遍历接口参数批量请求不存在的 ID、手机号、订单号。这种请求通常是自动化脚本QPS 可以拉得很高。第二类业务数据本身不存在。比如用户在前端发起了一个查询但后端对应的记录因为未上线、已删除、权限不足等原因查不到。当一个功能刚上线、历史数据还没迁移完成时这种情况最明显。第三类参数格式问题。调用方传入了非法格式的 ID例如把字符串拼进数值型主键字段底层查询自然永远查不到结果。3.2 故障演进路径只要线上存在上面任意一类场景故障演进是有固定路径的少量穿透请求到达应用层缓存未命中应用去查数据库。穿透请求量持续增加数据库连接池中的连接开始不够用。正常业务的数据库查询也需要等待连接接口响应时间拉长。上层服务开始超时重试重试又带来更多请求形成恶性循环。如果数据库没有做好连接数和 CPU 保护数据库实例可能直接进入高负载状态最终导致整条业务链路不可用。3.3 用数字感受一下压力假设数据库单机最多能扛 5000 QPS 的简单查询如果穿透请求打到 2 万 QPS即使正常业务只需要几百 QPS数据库也会被这 2 万无效查询压垮。穿透请求的成本极低但数据库处理一个无效查询的成本和有效查询几乎一样这才是最棘手的地方。4. 适用场景与使用边界4.1 适合用什么场景基于主键 ID 查询详情的接口例如用户详情、订单详情、商品详情。外部开放接口或容易被脚本刷的接口。缓存命中率偏低的业务例如数据冷热不均衡的系统。新系统上线初期大量 key 尚未被预热空查询比例较高。4.2 不适合什么场景写入频繁且几乎不读的数据没有必要做缓存防护做了反而增加一致性问题。数据库查询本身极快且压力不大的内部接口加防护层反而浪费资源。key 数量极大且生命周期极短的数据比如实时日志流布隆过滤器维护成本太高。4.3 合规与安全边界需要特别提醒在设计防护方案时涉及用户 ID、手机号、订单号等敏感数据日志和监控中不要记录完整的业务数据。做恶意请求拦截时需要基于真实业务规则判断不能因为某个用户触发多次空查询就直接封禁账号要在保护系统的同时避免误伤正常用户。生产环境做压测前必须先申请测试账号和测试链路避免对线上数据库造成次生故障。5. 防护方案一缓存空值成本最低的一层保安5.1 核心思路数据库查不到数据时不要直接返回 null而是把一个特殊标记写入缓存并设置较短的过期时间。这样后续相同请求在 TTL 内直接命中缓存看到标记后直接返回空结果不再查数据库。缓存空值方案适合大多数业务实现简单不需要引入额外组件。它的缺点是每个不存在的 key 都会占据一份 Redis 内存如果攻击者用随机 ID 不停构造请求缓存中会出现大量无效 key反而带来内存压力。因此空值的 TTL 必须比正常数据短很多。5.2 Java 实现示例public class CachePenetrationGuard { private final StringRedisTemplate redisTemplate; private final UserMapper userMapper; private static final String EMPTY_FLAG EMPTY; // 正常数据缓存 10 分钟 private static final long NORMAL_TTL_MINUTES 10; // 空值缓存只放 2 分钟避免大量空 key 堆积 private static final long EMPTY_TTL_MINUTES 2; public UserVO getUserById(String userId) { String cacheKey user:detail: userId; // 第一步查缓存 String cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { // 命中空值标记直接返回 null不查数据库 if (EMPTY_FLAG.equals(cached)) { return null; } return JSON.parseObject(cached, UserVO.class); } // 第二步缓存未命中查数据库 UserVO user userMapper.selectById(userId); if (user ! null) { redisTemplate.opsForValue().set( cacheKey, JSON.toJSONString(user), NORMAL_TTL_MINUTES, TimeUnit.MINUTES); } else { redisTemplate.opsForValue().set( cacheKey, EMPTY_FLAG, EMPTY_TTL_MINUTES, TimeUnit.MINUTES); } return user; } }5.3 注意事项空值标记要能和正常数据区分开。建议用一个业务中不会出现的字符串例如EMPTY或者用一个包装对象保存类型字段避免误把空值当真实数据解析。空值 TTL 不能太长。一般设置 1 到 5 分钟。如果数据被创建后用户立刻需要能看到TTL 过长会导致短时间数据不一致。如果业务对一致性要求较高可以缩到 30 秒左右。当数据库写入新数据时主动删除对应的空值缓存可以缩短不一致时间。在新增用户、创建订单等写入逻辑里执行完数据库写入后直接删除缓存 key下一轮查询自然读到新值。5.4 优点与局限这个方案的优点是实现成本低、立竿见影不用引入新的中间件。局限是只能拦截“已经出现过一次”的 key如果攻击者每次都用全新随机 ID缓存空值就没有命中机会内存还可能被打满。因此缓存空值适合配合下面几种方案一起用。6. 防护方案二布隆过滤器入口处先拦一道6.1 原理解析布隆过滤器是一个位数组加多个哈希函数构成的数据结构。添加元素时把元素经过 k 个哈希函数映射到位数组的 k 个位置并把对应位置置为 1。判断元素是否存在时如果所有映射位置都是 1则元素可能存在如果任意一个位置是 0则元素一定不存在。布隆过滤器有两个核心特点判断“不存在”是绝对准确的。判断“存在”有一定概率误判也就是把不存在的元素误判为存在。这个特点正好适合缓存穿透防护查询前先用布隆过滤器判断 key 是否存在如果过滤器说“一定不存在”直接返回空结果只有过滤器说“可能存在”时才允许进入后续缓存和数据库查询逻辑。6.2 应用内布隆过滤器实现在单机应用或数据量可控的场景可以使用 Guava 提供的BloomFilter。Component public class UserBloomFilter { private final BloomFilterLong userIdFilter; public UserBloomFilter() { // 预计插入 100 万个用户 ID误判率设为 1% userIdFilter BloomFilter.create( Funnels.longFunnel(), 1_000_000L, 0.01); } PostConstruct public void init() { ListLong userIds userMapper.selectAllIds(); userIds.forEach(userIdFilter::put); System.out.println(布隆过滤器初始化完成加载 ID 数量 userIds.size()); } public boolean mightExist(Long userId) { return userIdFilter.mightContain(userId); } }查询服务在查缓存前先调用mightExist方法public UserVO getUserById(Long userId) { if (!userBloomFilter.mightExist(userId)) { // 布隆过滤器判断一定不存在直接返回 return null; } // 再走缓存和数据库查询 return doQuery(userId); }这个方案能挡住绝大多数不存在的 key 的请求因为过滤器对“一定不存在”的判断不会出错。只有那些被误判为存在的 key 会继续向下传递这部分请求再交给缓存空值方案去拦截。6.3 分布式场景与 Redis 布隆过滤器单机 Guava 布隆过滤器在应用重启后会丢失数据需要重新加载全量 ID。如果应用是多实例部署每个实例都要维护一份数据一致性很难保证。这时更推荐使用 Redis 布隆过滤器。第一种方式是使用 Redis 4.0 提供的BF.ADD、BF.EXISTS命令需要 Redis 加载布隆过滤器模块。第二种方式是使用 Redisson 等客户端提供的分布式布隆过滤器RBloomFilterLong bloomFilter redisson.getBloomFilter(user-id-bloom); // 初始化预计元素数量 100 万误判率 1% bloomFilter.tryInit(1_000_000L, 0.01); // 启动时加载已有 ID ListLong userIds userMapper.selectAllIds(); userIds.forEach(bloomFilter::add); // 查询时判断 boolean exists bloomFilter.contains(userId);Redisson 会把位数组存储在 Redis 中多个应用实例共享同一个过滤器重启应用后不需要重新加载全量数据。6.4 使用布隆过滤器要注意的问题第一个问题是删除操作。布隆过滤器不支持删除单个元素。如果一个业务 ID 被删除后不再有效它仍然会被过滤器判断为可能存在多出的请求会继续往下走。解决办法是定期重建过滤器或者在关键删除操作后触发全量重建。第二个问题是初始化成本。全量加载数据库 ID 到布隆过滤器时如果数据量很大启动过程会比较慢。可以选择在低峰期做异步初始化或者用批量管道写入 Redis。第三个问题是误判率。误判率越低需要的位数组空间越大。通常设置 0.01 到 0.001 已经足够。数据量增长后原过滤器容量不足误判率会上升需要基于实际数据量重新评估容量。7. 防护方案三参数校验、限流与降级缓存空值和布隆过滤器主要解决“key 不存在”的穿透问题。但有时候请求本身就不该进入查询链路或者流量已经高到超出系统承受能力这时需要更前置的拦截手段。7.1 参数合法性校验第一层拦截是参数校验。很多穿透请求是参数本身就不合法比如主键 ID 应为正整数却传入了负数或 0。ID 应为定长字符串却传入了超长字符串。用户手机号应为 11 位却传入了字母组合。这些请求可以在 Controller 层直接拦截返回参数错误完全不需要进入查询逻辑。GetMapping(/user/{userId}) public ResultUserVO getUserById(PathVariable Long userId) { // 参数校验ID 必须为正整数且不超过业务上限 if (userId null || userId 0 || userId 100_000_000L) { return Result.error(非法用户 ID); } // 后续缓存和数据库查询 UserVO user userService.getById(userId); return Result.ok(user); }参数校验不能只做前后端联动校验后端服务必须独立校验。尤其是在开放接口场景下调用方可能完全绕过前端页面直接发 HTTP 请求。后端校验是最后一道参数防线。7.2 限流限流的核心目标是控制“进入查询链路”的请求速率。即使前面几层都没拦住限流也能保证数据库的 QPS 不会超过安全阈值。常用的限流方案有三种单机限流使用 Guava RateLimiter 或 Semaphore 限制单实例的并发查询数。分布式限流使用 Redis Lua 脚本实现令牌桶或滑动窗口算法。网关/Sentinel 限流在流量进入应用前统一拦截。以 Sentinel 为例可以在查询接口上配置 QPS 限流规则# Sentinel 限流规则配置示意 # 资源名/user/{userId} # 阈值单机 QPS 500 # 流控效果快速失败被限流的请求直接返回“系统繁忙请稍后重试”不再向下传递。限流是最后的保护伞它可以牺牲一部分请求但不让数据库被打垮。7.3 熔断与降级当数据库或下游服务的错误率升高时需要触发熔断。熔断打开后后续请求在短时间内直接走降级逻辑不调用数据库。降级策略可以是返回默认数据、返回历史缓存快照或者直接返回一个可读的错误提示。在缓存穿透防护中熔断降级尤其重要。如果数据库已经被异常流量打到高负载继续让所有请求进入查询链路只会加速崩溃。通过熔断降低对数据库的调用频率给数据库留出恢复时间。8. 防护方案四热点数据多级缓存与兜底布隆过滤器和缓存空值可以拦截大部分穿透但面对超高并发时应用层到 Redis 的连接也是资源。如果同一个热点 key 被大量请求同时命中Redis 虽然能扛住应用线程和网络带宽也有压力。更合理的方式是把热点数据再做一层本地缓存。8.1 本地缓存兜底应用本地缓存可以使用 Caffeine 或 Guava Cache放在 Redis 之前。查询流程变成查本地缓存命中则直接返回。本地缓存未命中查 Redis。Redis 未命中查数据库。数据库结果回写 Redis本地缓存也保存一份。本地缓存放在应用进程内查询不走网络性能极好。但由于每个实例各自保存一份数据一致性最弱。它适合读多写少、一致性要求不高的热点数据例如商品详情、用户昵称、配置项等。8.2 数据库连接池保护防护方案再完善也不可能做到 100% 拦截所有无效请求。数据库连接池本身的参数配置也需要调整。连接池的maximum-pool-size不宜设置过大否则数据库线程数被拉高操作系统上下文切换成本暴涨整体吞吐反而下降。合理设置等待队列长度让超出能力的请求快速失败而不是无限排队等待。以 HikariCP 为例常见的合理配置思路是spring: datasource: hikari: # 最大连接数按数据库实例规格估算 maximum-pool-size: 20 # 连接最大空闲时间 idle-timeout: 600000 # 获取连接的超时时间超过则快速失败 connection-timeout: 2000这些参数没有固定标准需要结合数据库规格、业务 QPS 和慢查询情况调整。核心原则是宁可快速失败不要让所有请求堆积在连接池等待队列里。9. 四种方案对比与选型建议方案实现成本内存/资源成本误判或副作用适用场景缓存空值最低每个空 key 占一份缓存空 key 过多会占内存空查询量不大、key 可枚举布隆过滤器中等位数组占用固定内存判断存在有误判率key 全量可加载、删除不频繁参数校验 限流 降级中低几乎无额外内存限流可能误伤正常请求开放接口、高并发入口多级缓存兜底中高增加本地内存占用数据一致性弱热点数据读多写少实际项目很少只用一个方案。最常见的组合是参数校验 缓存空值这是最基本的配置任何查询类接口都应该做。数据量可控且 ID 有规律的业务再叠加布隆过滤器。高并发且容易被脚本刷的开放接口再加上限流和熔断降级。热点数据访问频繁时再加本地缓存。从成本角度考虑建议按顺序逐步加先做参数校验和缓存空值观察缓存命中率如果数据库压力依然高再加布隆过滤器如果还存在超预期流量再上限流。不要一上来就全上每一层都有维护成本。10. 部署效果与性能观察上线防护方案后不能只看功能正常还要量化验证效果。10.1 观察缓存命中率缓存命中率是判断穿透防护是否有效的核心指标。在 Redis 中可以使用INFO stats命令查看keyspace_hits: 98000 keyspace_misses: 2000命中率 keyspace_hits / (keyspace_hits keyspace_misses)。正常情况下缓存命中率越高说明数据库查询次数越少。如果一个业务接口的缓存命中率长期低于 80%就需要检查是否有大量无效 key 在穿透。在业务层也可以埋点统计进入查询接口的总请求数、实际查询数据库的次数、命中空值缓存的次数分别打点上报到监控系统。10.2 确认数据库压力下降数据库侧的观察指标包括数据库 QPS压在 MySQL 或达梦数据库、Oracle 上的查询量是否下降。数据库连接数通过连接池监控查看活跃连接数是否趋于平稳。慢查询数量是否存在大量重复的无效查询语句。CPU 使用率数据库实例 CPU 是否回到正常水位。上线前先在测试环境压测模拟一批不存在的 key 请求对比加防护前后的数据库 QPS 和接口响应时间。上线后不要立刻做全量切换可以先放 5% 流量观察指标确认数据库侧压力明显下降后再逐步放量。10.3 内存占用变化缓存空值方案会新增 Redis 内存占用布隆过滤器的位数组也会占用一定空间。上线前要预估内存变化空值缓存按条数估算每条大约几十字节乘以 TTL 时间窗内的空 key 数量。布隆过滤器按公式计算位数组长度或者直接根据误判率和预估元素数调整tryInit参数。如果发现 Redis 内存增长过快优先检查空值 TTL 是否过长或者布隆过滤器误判率是否设置过严导致位数组过大。10.4 压测建议压测时使用 JMeter 或其他压测工具分别测三组场景正常存在的 key 请求观察基线 QPS 和响应时间。不存在的随机 key 请求观察数据库 QPS 是否暴涨。混合场景70% 正常 key 加 30% 随机不存在 key观察开启防护前后的性能差异。压测环境要与生产环境的数据库规格、网络延迟尽量保持一致否则压测结果只能作为参考不能直接推导线上容量。11. 常见问题与排查方法问题现象可能原因排查方式解决方案加了缓存空值后内存涨得很快空 key TTL 太长随机 key 太多查看 Redis key 数量和内存占用缩短空值 TTL增加布隆过滤器前置拦截布隆过滤器拦截后正常数据也查不到ID 未正确加载到过滤器检查启动初始化日志确认数据量重建过滤器使用增量加载脚本布隆过滤器误判率高数据量超过预估容量位数组太小查看过滤器容量和误判率参数扩容位数组重新初始化限流把正常流量也限掉了阈值设置过小或限流规则作用域过大查看限流日志和监控曲线调大阈值按接口拆分限流规则数据库 QPS 仍然很高防护层未覆盖所有查询入口检查是否有其他代码路径绕过缓存直接查库统一走缓存查询入口禁止散落查询代码缓存空值导致数据不一致数据更新后空值缓存未删除数据写入时是否执行了删除缓存操作写入逻辑中主动删除旧 key缩短空值 TTL重启应用后布隆过滤器失效使用应用内 Guava 过滤器数据未持久化检查重启后的命中情况改用 Redis 布隆过滤器或启动时全量重建Redis 连接数过多加了布隆过滤器但 Redis 连接池配置过小查看 Redis 客户端连接数调大连接池或对热点 key 增加本地缓存排查时建议从一条完整请求链路开始请求进入应用后是否先过参数校验再过布隆过滤器再查本地缓存再查 Redis最后才到数据库。每一个环节打印一条轻量日志记录命中状态就能快速定位是哪一层没有拦住。12. 最佳实践与合规提醒12.1 工程实践建议第一防护方案要统一封装不要散落在业务代码里。建议做一个公共方法比如getWithBloomFilterAndEmptyCache业务代码只调用一个方法内部完成布隆过滤器判断、缓存查询、空值写入的逻辑。这样新接入的业务不需要重新理解整套流程也不容易漏掉某一层防护。第二空值缓存和正常缓存的 key 命名要能区分。建议使用不同的前缀例如empty:user:detail:9527和user:detail:9527方便排查问题时快速识别。第三布隆过滤器需要定期维护。业务数据量增长时原过滤器容量可能不足。建议在数据量增长到预估值的 80% 时准备重建过滤器。第四监控告警要覆盖关键指标。至少要配置以下告警缓存命中率低于阈值。数据库活跃连接数超过连接池上限的 70%。接口响应时间 P99 超过业务 SLA。Redis 内存占用超过实例容量的 70%。第五不要在代码和日志中记录完整用户 ID、手机号等敏感信息。排查问题需要关联请求时可以使用脱敏后的标识。12.2 合规与安全使用边界在设计拦截和限流规则时要基于业务合理性不能因为用户触发了空查询就永久拉黑用户。拉黑账号、限制访问等功能涉及用户权益必须有明确的业务规则和管理流程。如果系统面向外部开放 API还需要做好调用方身份认证和配额管理。每个调用方分配独立的 AppKey 和配额单调用方超量时只对该调用方限流不影响其他正常调用方。这样即使有恶意调用方在刷不存在的 key影响范围也能被控制在最小单元。涉及商业数据、用户个人信息时缓存中的数据同样需要遵循权限管理和加密要求。存储用户缓存信息时按业务需要设置合理的 TTL避免敏感数据长时间滞留缓存层。13. 总结缓存穿透是数据库最常见的人为灾害之一但它的防护手段并不复杂。优先级建议从低到高先把参数校验做扎实再上缓存空值数据量大之后加布隆过滤器最后用限流熔断兜底。任何方案都要以数据说话。上线前在测试环境压测三组场景上线后盯住缓存命中率、数据库 QPS、Redis 内存三个指标。穿透请求拦截得干净数据库压力自然就下来了。如果现在项目里还没有任何穿透防护建议先从缓存空值开始动手这是成本最低、见效最快的一步。写完代码后别忘了补上监控指标否则下次故障来了你可能都不知道是哪一层被穿透的。
