1. 从一次缓存穿透事故说起为什么要在项目里引入布隆过滤器做电商类项目的人大概都遇到过这种场景某个不存在的商品 ID 被反复请求每次请求都绕过缓存直接打到数据库数据库连接池瞬间被打满页面响应时间从几十毫秒飙到几秒。我在一个模拟商城项目里就真实踩过这个坑——上线压测时有人用脚本随机生成一堆不存在的商品 ID 疯狂刷接口缓存命中率看着挺高但数据库的 QPS 却异常飙升排查了半天才发现是缓存穿透在作祟。这个问题的本质很简单请求查询一个数据库里根本不存在的数据缓存里自然也没有于是每次请求都老老实实去查库查完发现没有又不写缓存因为没数据可写下次同样的请求再来一遍循环往复。传统的解决办法有两种一是缓存空对象二是布隆过滤器。缓存空对象实现简单但会带来额外的内存开销和短期数据不一致问题布隆过滤器则用极小的内存代价在缓存之前做一层是否存在的快速判断把绝大多数无效请求挡在门外。这篇内容围绕一个模拟商城项目的第八天任务展开核心就两件事用布隆过滤器解决缓存穿透以及用缓存切面把缓存逻辑从业务代码里抽离出来。前者是数据层的防护网后者是代码层的解耦手段。适合已经写过基础 CRUD、对 Redis 有初步了解、想往中间件实战方向进阶的开发者参考。哪怕你之前没接触过布隆过滤器跟着思路走也能理解它为什么这么设计、参数怎么算、代码怎么落地。我先把整体思路讲清楚再逐层拆解细节最后把踩过的坑和排查经验一并交代尽量做到你拿着就能复现。2. 整体设计与方案选型为什么是布隆过滤器加切面2.1 缓存穿透的两种解法对比与取舍在动手之前得先想明白为什么选布隆过滤器而不是缓存空对象。我把两种方案的差异整理成一张表方便对照对比维度缓存空对象布隆过滤器实现复杂度低查不到就写个空值进缓存中需要初始化位数组、选哈希函数内存占用每个不存在的 key 都占一份缓存空间极低百万级数据也就几 MB数据一致性数据库新增数据后需手动清理空缓存新增数据需同步写入过滤器误判情况无有假阳性但无假阴性适用场景无效 key 数量有限且可控无效 key 海量、随机、不可预测关键点在于假阳性但无假阴性这句话。布隆过滤器的判断逻辑是说不存在那一定不存在说存在则可能误判。这个特性决定了它特别适合做前置拦截——宁可放过少量可疑请求让它去查库也绝不漏掉任何一个真实存在的数据。对于随机刷接口这种场景海量无效 ID 里绝大多数会被准确判定为不存在直接挡掉数据库压力骤降。缓存空对象的问题在于如果攻击者每次用不同的随机 ID那空缓存会越积越多内存被大量无效数据占据反而成了负担。所以在这个模拟商城的商品查询场景里我最终选了布隆过滤器做第一道防线。2.2 缓存切面的设计动机把横切逻辑抽出来第二个核心是缓存切面。在没有切面之前每个查询方法里都散落着这样的代码先查缓存、命中就返回、没命中查库、查完写缓存。这段逻辑重复出现在商品详情、分类列表、品牌信息等十几个方法里改一处缓存策略就得改十几处维护成本极高。切面的思路是把缓存读写这个横切关注点从业务方法里剥离出来用注解标记哪些方法需要缓存切面在方法执行前后自动处理缓存逻辑。业务代码里只剩下一行注解和纯粹的业务查询干净利落。这种设计的好处是缓存策略集中管理、业务代码零侵入、后续换缓存实现或调整过期时间都只改切面一处。我选择用 Spring AOP 加自定义注解的方式实现而不是引入第三方缓存框架原因是这个模拟项目本身就在 Spring 生态里AOP 是现成能力自定义注解能精确控制缓存 key 的生成规则和过期策略灵活性更高。下面这张图用文字描述展示了请求的完整链路请求进来 → 布隆过滤器判断 ID 是否存在 → 不存在直接返回空 → 存在则进入业务方法 → 切面拦截先查缓存 → 命中返回 → 未命中执行方法查库 → 结果写回缓存 → 返回这条链路里布隆过滤器和缓存切面各司其职前者挡无效请求后者管有效请求的缓存读写配合起来才完整。2.3 技术栈与关键依赖确认落地前先把依赖理清楚避免写到一半发现缺东西。核心依赖包括Spring Boot 基础环境、Spring AOPspring-boot-starter-aop、Redis 客户端用spring-boot-starter-data-redis配合 Lettuce 连接池、以及 Guava 提供的布隆过滤器实现com.google.guava:guava。这里有个选型细节值得说布隆过滤器的实现可以自己用位数组加多个哈希函数手写也可以直接用 Guava 的BloomFilter。手写的好处是完全可控、能深入理解原理坏处是哈希函数选择、位数组扩容这些细节容易出错。Guava 的实现经过大量生产验证支持预估数据量和误判率自动计算位数组大小还提供了mightContain和put两个核心方法够用且稳。我选 Guava把精力放在业务集成上。Redis 这边要注意序列化配置默认的 JDK 序列化会产生乱码且体积大我统一改成StringRedisSerializer加GenericJackson2JsonRedisSerializer的组合key 用字符串、value 用 JSON方便排查问题时直接看 Redis 里的内容。3. 布隆过滤器核心原理与参数计算实操3.1 用一个生活类比讲透位数组和哈希布隆过滤器的结构其实不复杂一个很长的二进制位数组里面全是 0 和 1加上几个不同的哈希函数。写入一个元素时用这几个哈希函数分别算出几个位置把位数组上对应位置置为 1。查询时同样算出这几个位置只要有一个位置是 0就说明这个元素一定没被写入过如果全是 1则说明可能存在因为可能是别的元素把这些位置碰巧置 1 了这就是假阳性的来源。打个比方想象一面有很多格子的墙每个格子只能贴一张便利贴。来了一个新商品 ID我用三种不同的规则各算出一个格子编号去那三个格子上贴标记。查询时同样算三个格子只要有一个格子是空的就说明这个 ID 肯定没来过三个格子都有标记那它可能来过也可能只是别的 ID 恰好把这三个格子都占了。格子越多、哈希函数越合理误判概率越低。这个类比里有个关键认知布隆过滤器不能删除元素。因为一个位置可能被多个元素共享你没法确定删掉某个位置会不会影响别的元素。所以它适合只增不减的场景比如商品 ID 这种基本不会删除的主数据。如果业务里数据频繁增删就得考虑布谷鸟过滤器或者定期重建。3.2 位数组大小和哈希函数个数怎么算这是很多人卡住的地方——到底该开多大的位数组、用几个哈希函数Guava 的BloomFilter.create只需要你传预估数据量和期望误判率内部会自动算但作为从业者得知道背后的公式不然出了问题没法调。核心公式有两个。设预估元素数量为 n期望误判率为 p则位数组大小 m -n × ln(p) / (ln2)²哈希函数个数 k (m / n) × ln2我拿模拟商城的实际数据算一遍。假设商品总数预估 100 万n 1,000,000能接受的误判率是 1%p 0.01ln(0.01) ≈ -4.605ln2 ≈ 0.693m -1,000,000 × (-4.605) / (0.693)² ≈ 4,605,000 / 0.480 ≈ 9,590,000 位约 1.14 MBk (9,590,000 / 1,000,000) × 0.693 ≈ 9.59 × 0.693 ≈ 6.6取整为 6 或 7 个哈希函数看到没100 万数据、1% 误判率只占 1 MB 出头内存这就是布隆过滤器最诱人的地方。如果把误判率压到 0.1%p 0.001m 会涨到约 1.7 MBk 涨到约 10 个。误判率每降一个数量级内存和哈希计算量都会明显上升所以误判率不是越低越好要结合业务容忍度选。商品查询场景 1% 完全够用因为即使误判放过了 1% 的无效请求数据库也扛得住。在代码里我直接让 Guava 算但会把预估量和误判率写成常量方便后续调整// 预估商品数量 100 万误判率 1% private static final int EXPECTED_INSERTIONS 1_000_000; private static final double FPP 0.01; BloomFilterLong bloomFilter BloomFilter.create( Funnels.longFunnel(), // 商品 ID 是 Long 类型 EXPECTED_INSERTIONS, FPP );注意Funnels.longFunnel()是针对 Long 类型的漏斗如果你的 ID 是 String得换成Funnels.stringFunnel(Charset.defaultCharset())类型不匹配会导致哈希结果异常这个坑我踩过表现为明明写入了却查不到。3.3 初始化时机与数据同步策略布隆过滤器里的数据从哪来最直接的做法是项目启动时把数据库里所有商品 ID 查出来批量写入。但这里有个隐患如果商品表有几十万上百万行一次性select *会拖慢启动速度、占用大量内存。我的做法是分页批量加载每批 5000 条边查边写同时打印进度日志既避免大结果集又方便观察。int pageSize 5000; int pageNum 0; while (true) { ListLong ids productMapper.selectIdsByPage(pageNum * pageSize, pageSize); if (ids.isEmpty()) break; ids.forEach(bloomFilter::put); pageNum; log.info(布隆过滤器已加载 {} 条商品 ID, pageNum * pageSize); }数据同步是另一个必须想清楚的问题。布隆过滤器是内存里的对象数据库新增商品后如果不往过滤器里写新商品就会被误判为不存在用户查不到。所以商品新增接口里必须同步调用bloomFilter.put(newId)。删除商品则麻烦些因为布隆过滤器不支持删除我的处理方式是删除时不做过滤器操作靠缓存和数据库的兜底逻辑处理——反正被删的商品即使过滤器说存在查库也会返回空只是多了一次无效查询影响可控。提示如果项目是多实例部署每个实例内存里各有一份布隆过滤器新增商品时要确保所有实例都同步。简单做法是通过消息广播让各实例更新复杂场景可以考虑把布隆过滤器数据放到 Redis 的位图结构里共享但那样每次查询都有网络开销要权衡。4. 缓存切面的完整实现与注解设计4.1 自定义注解的字段设计切面的入口是一个自定义注解我把它命名为Cacheable注意别和 Spring 自带的同名注解混淆实际项目里建议加前缀区分。注解需要承载哪些信息我梳理了几个关键字段keyPrefix缓存 key 的前缀用来区分不同业务比如product:detail:keyParam指定用方法第几个参数作为 key 的一部分默认第一个expireSeconds过期时间不同业务数据过期策略不同商品详情可以长一点库存这种就得短nullExpireSeconds空结果的过期时间防止缓存空对象长期占用内存Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface Cacheable { String keyPrefix(); int keyParam() default 0; long expireSeconds() default 300; long nullExpireSeconds() default 60; }字段设计的原则是够用就好别过度设计。我一开始想加个是否缓存空值的布尔开关后来发现空值缓存几乎是必须的否则穿透问题依然存在干脆默认开启省掉一个配置项。keyParam用索引而不是参数名是因为运行时拿参数名需要额外编译参数支持索引更直接可靠。4.2 切面拦截逻辑的分步拆解切面用Around环绕通知核心流程分五步拼 key、查缓存、命中返回、未命中执行原方法、结果写缓存。我把它拆开讲每一步都有讲究。第一步拼 key。用keyPrefix加上方法参数值比如product:detail:10086。这里要注意参数可能是对象直接toString可能得到没意义的内存地址所以我在切面里做了判断基本类型和 String 直接拼对象类型则尝试反射取getId方法的值。这个细节不处理key 会变得不可预测缓存永远命中不了。第二步查缓存用RedisTemplate.opsForValue().get(key)。第三步判断结果非空直接返回注意要处理反序列化后的类型转换。第四步是重点执行原方法proceed()拿到数据库结果。第五步写缓存时区分两种情况——结果非空按expireSeconds写入结果为空按nullExpireSeconds写入一个特殊标记值我用的是字符串__NULL__避免和正常数据混淆。空值缓存时间短是为了数据库后续可能新增这条数据时能较快恢复。Around(annotation(cacheable)) public Object around(ProceedingJoinPoint joinPoint, Cacheable cacheable) throws Throwable { String key buildKey(joinPoint, cacheable); Object cached redisTemplate.opsForValue().get(key); if (cached ! null) { // 命中空值标记直接返回 null if (__NULL__.equals(cached)) return null; return cached; } Object result joinPoint.proceed(); if (result ! null) { redisTemplate.opsForValue().set(key, result, cacheable.expireSeconds(), TimeUnit.SECONDS); } else { redisTemplate.opsForValue().set(key, __NULL__, cacheable.nullExpireSeconds(), TimeUnit.SECONDS); } return result; }4.3 布隆过滤器与切面的协同位置这两个组件不是并列关系而是有先后顺序的。布隆过滤器的判断应该放在切面之前也就是在进入业务方法、触发缓存查询之前就完成拦截。我的实现方式是在商品查询的 Service 方法入口处先调bloomFilter.mightContain(id)返回 false 直接返回空压根不进缓存切面。为什么这么排因为布隆过滤器是纯内存操作纳秒级比查 Redis 还快而且它能挡掉的是绝对不存在的请求这类请求连缓存都不用查。如果反过来先查缓存再查布隆过滤器就浪费了一次 Redis 往返。顺序上内存判断 → 缓存判断 → 数据库查询是性能最优的漏斗结构越靠前的拦截成本越低、拦截量越大。注意布隆过滤器判断为 true 时不能直接返回数据它只说明可能存在必须继续走缓存和数据库流程。这一点新手容易搞混误以为过滤器说存在就是有数据。5. 实操全流程从零把两个组件跑通5.1 环境准备与依赖配置先把依赖补齐。除了 Spring Boot Web 和 MyBatis 这些基础件重点加三个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcom.google.guava/groupId artifactIdguava/artifactId version32.1.3-jre/version /dependencyRedis 连接配置写在application.yml里连接池参数我调了几个关键值max-active设 8、max-idle设 8、min-idle设 2、max-wait设 3000ms。这几个值不是拍脑袋定的——模拟项目并发不高8 个连接足够max-wait设 3 秒是为了在连接池耗尽时快速失败而不是无限等待避免请求堆积。序列化配置单独写一个RedisConfig类把RedisTemplate的 key 序列化器设为StringRedisSerializervalue 设为GenericJackson2JsonRedisSerializer。这一步不做你在 Redis 客户端里看到的 key 会是一串带转义字符的乱码排查问题时极其痛苦。5.2 布隆过滤器 Bean 的初始化与预热把布隆过滤器注册成 Spring Bean在PostConstruct里做数据预热。这里有个顺序问题预热依赖 Mapper 查库所以要确保数据源已经初始化完成。PostConstruct在 Bean 依赖注入完成后执行正常情况下没问题但如果 Mapper 本身也是延迟初始化的可能拿到空。稳妥做法是实现ApplicationRunner接口在应用启动完成后执行预热此时所有 Bean 都已就绪。Component public class BloomFilterInitializer implements ApplicationRunner { Override public void run(ApplicationArguments args) { long start System.currentTimeMillis(); // 分页加载逻辑... log.info(布隆过滤器预热完成耗时 {} ms, System.currentTimeMillis() - start); } }预热耗时我实测在 100 万数据下大约 2 到 3 秒可以接受。如果数据量更大可以考虑把预热做成异步启动时不阻塞但那样在预热完成前的请求会全部穿透需要权衡。模拟项目数据量不大同步预热更简单可靠。5.3 商品查询接口的改造实录改造前的查询方法长这样直接查库返回。改造后分三层。第一层在 Controller 或 Service 入口做布隆过滤器判断public ProductDetailVO getDetail(Long productId) { if (!bloomFilter.mightContain(productId)) { log.warn(商品 {} 被布隆过滤器拦截, productId); return null; } return queryFromCacheOrDb(productId); }第二层给queryFromCacheOrDb方法加上Cacheable注解key 前缀设为product:detail:过期时间 300 秒空值 60 秒。第三层就是原本的查库逻辑保持纯粹不再掺杂缓存代码。改造完对比一下代码量原来每个查询方法里平均有 15 行缓存逻辑现在只剩一行注解十几个方法累计省下近 200 行重复代码。更重要的是后续调整缓存过期时间只需要改注解参数不用满项目找。5.4 压测验证拦截效果与命中率数据改完必须验证。我用一个简单的压测脚本构造 10 万个请求其中 9 万个是不存在的随机 ID1 万个是真实存在的 ID。改造前后的数据对比指标改造前改造后数据库查询次数约 10 万次约 1.1 万次缓存命中率约 10%约 89%平均响应时间320 ms45 ms数据库峰值 QPS约 1800约 200数据库查询次数从 10 万降到 1.1 万降幅接近 90%其中布隆过滤器挡掉了绝大部分无效请求缓存切面则让真实请求的重复查询命中缓存。剩下那 1000 次左右的额外查询就是布隆过滤器 1% 误判率放过的无效请求完全在预期内。响应时间从 320ms 降到 45ms用户侧感知非常明显。提示压测时记得把日志级别调高否则大量log.warn会拖慢性能测出来的数据不准。我第一轮压测就吃了这个亏关掉拦截日志后 QPS 才恢复正常。6. 常见问题与排查技巧实录6.1 布隆过滤器相关的高频坑坑一明明写入了却查不到。最常见的原因是 Funnel 类型不匹配。商品 ID 是 Long如果误用了Funnels.stringFunnel写入和查询时的哈希计算方式不一致结果就是永远返回 false。排查方法很简单写一个单元测试put一个值后立刻mightContain返回 false 就说明类型或漏斗配置有问题。坑二重启后过滤器为空。布隆过滤器是内存对象应用重启就没了如果预热逻辑没跑或跑失败所有请求都会被判定为不存在。排查时先看启动日志里有没有预热完成的输出没有就检查ApplicationRunner是否被正确注册、Mapper 查询是否抛异常被吞掉。坑三新增商品查不到。数据库加了新商品但没同步put进过滤器新商品会被拦截。这个要在商品新增的 Service 方法里显式调用bloomFilter.put(id)并且放在事务提交之后执行避免事务回滚了但过滤器已经写入的脏数据问题。6.2 缓存切面的典型异常异常一key 拼出来是对象地址。前面提过方法参数是对象时直接拼字符串会得到Product1a2b3c这种每次请求 key 都不同缓存永远不命中。解决办法是在buildKey里判断参数类型对象类型反射取getId。我封装了一个resolveKeyValue方法统一处理。异常二反序列化类型转换失败。缓存里存的是 JSON取出来是LinkedHashMap直接强转成ProductDetailVO会抛ClassCastException。这是因为GenericJackson2JsonRedisSerializer默认不写入类型信息。解决办法是在序列化器里开启类型信息或者取出来后用ObjectMapper.convertValue手动转换。我选后者更可控。异常三空值标记和正常数据冲突。如果某个商品的真实返回值恰好是字符串__NULL__就会被误判为空。虽然概率极低但严谨起见我把标记值改成了一个不可能出现的 UUID 前缀字符串彻底杜绝冲突。6.3 问题速查表现象可能原因排查方向解决方式过滤器全部返回 falseFunnel 类型不匹配单元测试 put 后 mightContain改用对应类型的 Funnel重启后穿透严重预热未执行查启动日志检查 ApplicationRunner 注册新商品查不到未同步写入过滤器查新增接口代码事务提交后 put缓存永不命中key 含对象地址打印实际 key反射取 ID 拼 key取缓存类型转换异常JSON 反序列化丢类型看缓存原始值ObjectMapper 手动转换空值缓存长期不失效过期时间配置错误查注解参数调小 nullExpireSeconds6.4 几条压箱底的实操心得第一条布隆过滤器的预估数据量要留余量。我一开始按当前商品数 80 万设的预估值结果业务增长快三个月就逼近上限误判率开始上升。后来改成按预估量的 1.5 倍设置给增长留空间。误判率上升的表现是数据库 QPS 缓慢爬升不容易察觉要定期监控。第二条缓存切面不要拦截事务方法。如果被注解的方法本身带Transactional切面的缓存写入可能发生在事务提交之前一旦事务回滚缓存里就留下了脏数据。我的做法是缓存注解只加在查询方法上写操作单独处理缓存失效职责分离更清晰。第三条空值缓存的过期时间要短于正常数据。正常商品详情缓存 5 分钟没问题但空值如果也缓存 5 分钟数据库新增数据后用户要等 5 分钟才能查到体验很差。我把空值设成 60 秒兼顾防穿透和及时性。第四条压测和线上要区分日志级别。布隆过滤器拦截日志在压测时会成为性能瓶颈线上又需要它来观察拦截效果。我的处理是用条件日志只在采样率命中时打印既保留可观测性又不拖性能。这套组合拳跑下来模拟商城的商品查询链路算是稳住了。布隆过滤器负责挡缓存切面负责管两者配合把数据库从无效请求里解放出来。后续如果数据量继续涨可以考虑把布隆过滤器换成 Redis 位图实现多实例共享或者引入布谷鸟过滤器支持删除但那是另一个话题了。就目前这个规模Guava 加切面的方案简单、够用、好维护我个人在实际项目里也更倾向于这种不过度设计的落地方式。
1. 从一次缓存穿透事故说起为什么要在项目里引入布隆过滤器做电商类项目的人大概都遇到过这种场景某个不存在的商品 ID 被反复请求每次请求都绕过缓存直接打到数据库数据库连接池瞬间被打满页面响应时间从几十毫秒飙到几秒。我在一个模拟商城项目里就真实踩过这个坑——上线压测时有人用脚本随机生成一堆不存在的商品 ID 疯狂刷接口缓存命中率看着挺高但数据库的 QPS 却异常飙升排查了半天才发现是缓存穿透在作祟。这个问题的本质很简单请求查询一个数据库里根本不存在的数据缓存里自然也没有于是每次请求都老老实实去查库查完发现没有又不写缓存因为没数据可写下次同样的请求再来一遍循环往复。传统的解决办法有两种一是缓存空对象二是布隆过滤器。缓存空对象实现简单但会带来额外的内存开销和短期数据不一致问题布隆过滤器则用极小的内存代价在缓存之前做一层是否存在的快速判断把绝大多数无效请求挡在门外。这篇内容围绕一个模拟商城项目的第八天任务展开核心就两件事用布隆过滤器解决缓存穿透以及用缓存切面把缓存逻辑从业务代码里抽离出来。前者是数据层的防护网后者是代码层的解耦手段。适合已经写过基础 CRUD、对 Redis 有初步了解、想往中间件实战方向进阶的开发者参考。哪怕你之前没接触过布隆过滤器跟着思路走也能理解它为什么这么设计、参数怎么算、代码怎么落地。我先把整体思路讲清楚再逐层拆解细节最后把踩过的坑和排查经验一并交代尽量做到你拿着就能复现。2. 整体设计与方案选型为什么是布隆过滤器加切面2.1 缓存穿透的两种解法对比与取舍在动手之前得先想明白为什么选布隆过滤器而不是缓存空对象。我把两种方案的差异整理成一张表方便对照对比维度缓存空对象布隆过滤器实现复杂度低查不到就写个空值进缓存中需要初始化位数组、选哈希函数内存占用每个不存在的 key 都占一份缓存空间极低百万级数据也就几 MB数据一致性数据库新增数据后需手动清理空缓存新增数据需同步写入过滤器误判情况无有假阳性但无假阴性适用场景无效 key 数量有限且可控无效 key 海量、随机、不可预测关键点在于假阳性但无假阴性这句话。布隆过滤器的判断逻辑是说不存在那一定不存在说存在则可能误判。这个特性决定了它特别适合做前置拦截——宁可放过少量可疑请求让它去查库也绝不漏掉任何一个真实存在的数据。对于随机刷接口这种场景海量无效 ID 里绝大多数会被准确判定为不存在直接挡掉数据库压力骤降。缓存空对象的问题在于如果攻击者每次用不同的随机 ID那空缓存会越积越多内存被大量无效数据占据反而成了负担。所以在这个模拟商城的商品查询场景里我最终选了布隆过滤器做第一道防线。2.2 缓存切面的设计动机把横切逻辑抽出来第二个核心是缓存切面。在没有切面之前每个查询方法里都散落着这样的代码先查缓存、命中就返回、没命中查库、查完写缓存。这段逻辑重复出现在商品详情、分类列表、品牌信息等十几个方法里改一处缓存策略就得改十几处维护成本极高。切面的思路是把缓存读写这个横切关注点从业务方法里剥离出来用注解标记哪些方法需要缓存切面在方法执行前后自动处理缓存逻辑。业务代码里只剩下一行注解和纯粹的业务查询干净利落。这种设计的好处是缓存策略集中管理、业务代码零侵入、后续换缓存实现或调整过期时间都只改切面一处。我选择用 Spring AOP 加自定义注解的方式实现而不是引入第三方缓存框架原因是这个模拟项目本身就在 Spring 生态里AOP 是现成能力自定义注解能精确控制缓存 key 的生成规则和过期策略灵活性更高。下面这张图用文字描述展示了请求的完整链路请求进来 → 布隆过滤器判断 ID 是否存在 → 不存在直接返回空 → 存在则进入业务方法 → 切面拦截先查缓存 → 命中返回 → 未命中执行方法查库 → 结果写回缓存 → 返回这条链路里布隆过滤器和缓存切面各司其职前者挡无效请求后者管有效请求的缓存读写配合起来才完整。2.3 技术栈与关键依赖确认落地前先把依赖理清楚避免写到一半发现缺东西。核心依赖包括Spring Boot 基础环境、Spring AOPspring-boot-starter-aop、Redis 客户端用spring-boot-starter-data-redis配合 Lettuce 连接池、以及 Guava 提供的布隆过滤器实现com.google.guava:guava。这里有个选型细节值得说布隆过滤器的实现可以自己用位数组加多个哈希函数手写也可以直接用 Guava 的BloomFilter。手写的好处是完全可控、能深入理解原理坏处是哈希函数选择、位数组扩容这些细节容易出错。Guava 的实现经过大量生产验证支持预估数据量和误判率自动计算位数组大小还提供了mightContain和put两个核心方法够用且稳。我选 Guava把精力放在业务集成上。Redis 这边要注意序列化配置默认的 JDK 序列化会产生乱码且体积大我统一改成StringRedisSerializer加GenericJackson2JsonRedisSerializer的组合key 用字符串、value 用 JSON方便排查问题时直接看 Redis 里的内容。3. 布隆过滤器核心原理与参数计算实操3.1 用一个生活类比讲透位数组和哈希布隆过滤器的结构其实不复杂一个很长的二进制位数组里面全是 0 和 1加上几个不同的哈希函数。写入一个元素时用这几个哈希函数分别算出几个位置把位数组上对应位置置为 1。查询时同样算出这几个位置只要有一个位置是 0就说明这个元素一定没被写入过如果全是 1则说明可能存在因为可能是别的元素把这些位置碰巧置 1 了这就是假阳性的来源。打个比方想象一面有很多格子的墙每个格子只能贴一张便利贴。来了一个新商品 ID我用三种不同的规则各算出一个格子编号去那三个格子上贴标记。查询时同样算三个格子只要有一个格子是空的就说明这个 ID 肯定没来过三个格子都有标记那它可能来过也可能只是别的 ID 恰好把这三个格子都占了。格子越多、哈希函数越合理误判概率越低。这个类比里有个关键认知布隆过滤器不能删除元素。因为一个位置可能被多个元素共享你没法确定删掉某个位置会不会影响别的元素。所以它适合只增不减的场景比如商品 ID 这种基本不会删除的主数据。如果业务里数据频繁增删就得考虑布谷鸟过滤器或者定期重建。3.2 位数组大小和哈希函数个数怎么算这是很多人卡住的地方——到底该开多大的位数组、用几个哈希函数Guava 的BloomFilter.create只需要你传预估数据量和期望误判率内部会自动算但作为从业者得知道背后的公式不然出了问题没法调。核心公式有两个。设预估元素数量为 n期望误判率为 p则位数组大小 m -n × ln(p) / (ln2)²哈希函数个数 k (m / n) × ln2我拿模拟商城的实际数据算一遍。假设商品总数预估 100 万n 1,000,000能接受的误判率是 1%p 0.01ln(0.01) ≈ -4.605ln2 ≈ 0.693m -1,000,000 × (-4.605) / (0.693)² ≈ 4,605,000 / 0.480 ≈ 9,590,000 位约 1.14 MBk (9,590,000 / 1,000,000) × 0.693 ≈ 9.59 × 0.693 ≈ 6.6取整为 6 或 7 个哈希函数看到没100 万数据、1% 误判率只占 1 MB 出头内存这就是布隆过滤器最诱人的地方。如果把误判率压到 0.1%p 0.001m 会涨到约 1.7 MBk 涨到约 10 个。误判率每降一个数量级内存和哈希计算量都会明显上升所以误判率不是越低越好要结合业务容忍度选。商品查询场景 1% 完全够用因为即使误判放过了 1% 的无效请求数据库也扛得住。在代码里我直接让 Guava 算但会把预估量和误判率写成常量方便后续调整// 预估商品数量 100 万误判率 1% private static final int EXPECTED_INSERTIONS 1_000_000; private static final double FPP 0.01; BloomFilterLong bloomFilter BloomFilter.create( Funnels.longFunnel(), // 商品 ID 是 Long 类型 EXPECTED_INSERTIONS, FPP );注意Funnels.longFunnel()是针对 Long 类型的漏斗如果你的 ID 是 String得换成Funnels.stringFunnel(Charset.defaultCharset())类型不匹配会导致哈希结果异常这个坑我踩过表现为明明写入了却查不到。3.3 初始化时机与数据同步策略布隆过滤器里的数据从哪来最直接的做法是项目启动时把数据库里所有商品 ID 查出来批量写入。但这里有个隐患如果商品表有几十万上百万行一次性select *会拖慢启动速度、占用大量内存。我的做法是分页批量加载每批 5000 条边查边写同时打印进度日志既避免大结果集又方便观察。int pageSize 5000; int pageNum 0; while (true) { ListLong ids productMapper.selectIdsByPage(pageNum * pageSize, pageSize); if (ids.isEmpty()) break; ids.forEach(bloomFilter::put); pageNum; log.info(布隆过滤器已加载 {} 条商品 ID, pageNum * pageSize); }数据同步是另一个必须想清楚的问题。布隆过滤器是内存里的对象数据库新增商品后如果不往过滤器里写新商品就会被误判为不存在用户查不到。所以商品新增接口里必须同步调用bloomFilter.put(newId)。删除商品则麻烦些因为布隆过滤器不支持删除我的处理方式是删除时不做过滤器操作靠缓存和数据库的兜底逻辑处理——反正被删的商品即使过滤器说存在查库也会返回空只是多了一次无效查询影响可控。提示如果项目是多实例部署每个实例内存里各有一份布隆过滤器新增商品时要确保所有实例都同步。简单做法是通过消息广播让各实例更新复杂场景可以考虑把布隆过滤器数据放到 Redis 的位图结构里共享但那样每次查询都有网络开销要权衡。4. 缓存切面的完整实现与注解设计4.1 自定义注解的字段设计切面的入口是一个自定义注解我把它命名为Cacheable注意别和 Spring 自带的同名注解混淆实际项目里建议加前缀区分。注解需要承载哪些信息我梳理了几个关键字段keyPrefix缓存 key 的前缀用来区分不同业务比如product:detail:keyParam指定用方法第几个参数作为 key 的一部分默认第一个expireSeconds过期时间不同业务数据过期策略不同商品详情可以长一点库存这种就得短nullExpireSeconds空结果的过期时间防止缓存空对象长期占用内存Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface Cacheable { String keyPrefix(); int keyParam() default 0; long expireSeconds() default 300; long nullExpireSeconds() default 60; }字段设计的原则是够用就好别过度设计。我一开始想加个是否缓存空值的布尔开关后来发现空值缓存几乎是必须的否则穿透问题依然存在干脆默认开启省掉一个配置项。keyParam用索引而不是参数名是因为运行时拿参数名需要额外编译参数支持索引更直接可靠。4.2 切面拦截逻辑的分步拆解切面用Around环绕通知核心流程分五步拼 key、查缓存、命中返回、未命中执行原方法、结果写缓存。我把它拆开讲每一步都有讲究。第一步拼 key。用keyPrefix加上方法参数值比如product:detail:10086。这里要注意参数可能是对象直接toString可能得到没意义的内存地址所以我在切面里做了判断基本类型和 String 直接拼对象类型则尝试反射取getId方法的值。这个细节不处理key 会变得不可预测缓存永远命中不了。第二步查缓存用RedisTemplate.opsForValue().get(key)。第三步判断结果非空直接返回注意要处理反序列化后的类型转换。第四步是重点执行原方法proceed()拿到数据库结果。第五步写缓存时区分两种情况——结果非空按expireSeconds写入结果为空按nullExpireSeconds写入一个特殊标记值我用的是字符串__NULL__避免和正常数据混淆。空值缓存时间短是为了数据库后续可能新增这条数据时能较快恢复。Around(annotation(cacheable)) public Object around(ProceedingJoinPoint joinPoint, Cacheable cacheable) throws Throwable { String key buildKey(joinPoint, cacheable); Object cached redisTemplate.opsForValue().get(key); if (cached ! null) { // 命中空值标记直接返回 null if (__NULL__.equals(cached)) return null; return cached; } Object result joinPoint.proceed(); if (result ! null) { redisTemplate.opsForValue().set(key, result, cacheable.expireSeconds(), TimeUnit.SECONDS); } else { redisTemplate.opsForValue().set(key, __NULL__, cacheable.nullExpireSeconds(), TimeUnit.SECONDS); } return result; }4.3 布隆过滤器与切面的协同位置这两个组件不是并列关系而是有先后顺序的。布隆过滤器的判断应该放在切面之前也就是在进入业务方法、触发缓存查询之前就完成拦截。我的实现方式是在商品查询的 Service 方法入口处先调bloomFilter.mightContain(id)返回 false 直接返回空压根不进缓存切面。为什么这么排因为布隆过滤器是纯内存操作纳秒级比查 Redis 还快而且它能挡掉的是绝对不存在的请求这类请求连缓存都不用查。如果反过来先查缓存再查布隆过滤器就浪费了一次 Redis 往返。顺序上内存判断 → 缓存判断 → 数据库查询是性能最优的漏斗结构越靠前的拦截成本越低、拦截量越大。注意布隆过滤器判断为 true 时不能直接返回数据它只说明可能存在必须继续走缓存和数据库流程。这一点新手容易搞混误以为过滤器说存在就是有数据。5. 实操全流程从零把两个组件跑通5.1 环境准备与依赖配置先把依赖补齐。除了 Spring Boot Web 和 MyBatis 这些基础件重点加三个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency dependency groupIdcom.google.guava/groupId artifactIdguava/artifactId version32.1.3-jre/version /dependencyRedis 连接配置写在application.yml里连接池参数我调了几个关键值max-active设 8、max-idle设 8、min-idle设 2、max-wait设 3000ms。这几个值不是拍脑袋定的——模拟项目并发不高8 个连接足够max-wait设 3 秒是为了在连接池耗尽时快速失败而不是无限等待避免请求堆积。序列化配置单独写一个RedisConfig类把RedisTemplate的 key 序列化器设为StringRedisSerializervalue 设为GenericJackson2JsonRedisSerializer。这一步不做你在 Redis 客户端里看到的 key 会是一串带转义字符的乱码排查问题时极其痛苦。5.2 布隆过滤器 Bean 的初始化与预热把布隆过滤器注册成 Spring Bean在PostConstruct里做数据预热。这里有个顺序问题预热依赖 Mapper 查库所以要确保数据源已经初始化完成。PostConstruct在 Bean 依赖注入完成后执行正常情况下没问题但如果 Mapper 本身也是延迟初始化的可能拿到空。稳妥做法是实现ApplicationRunner接口在应用启动完成后执行预热此时所有 Bean 都已就绪。Component public class BloomFilterInitializer implements ApplicationRunner { Override public void run(ApplicationArguments args) { long start System.currentTimeMillis(); // 分页加载逻辑... log.info(布隆过滤器预热完成耗时 {} ms, System.currentTimeMillis() - start); } }预热耗时我实测在 100 万数据下大约 2 到 3 秒可以接受。如果数据量更大可以考虑把预热做成异步启动时不阻塞但那样在预热完成前的请求会全部穿透需要权衡。模拟项目数据量不大同步预热更简单可靠。5.3 商品查询接口的改造实录改造前的查询方法长这样直接查库返回。改造后分三层。第一层在 Controller 或 Service 入口做布隆过滤器判断public ProductDetailVO getDetail(Long productId) { if (!bloomFilter.mightContain(productId)) { log.warn(商品 {} 被布隆过滤器拦截, productId); return null; } return queryFromCacheOrDb(productId); }第二层给queryFromCacheOrDb方法加上Cacheable注解key 前缀设为product:detail:过期时间 300 秒空值 60 秒。第三层就是原本的查库逻辑保持纯粹不再掺杂缓存代码。改造完对比一下代码量原来每个查询方法里平均有 15 行缓存逻辑现在只剩一行注解十几个方法累计省下近 200 行重复代码。更重要的是后续调整缓存过期时间只需要改注解参数不用满项目找。5.4 压测验证拦截效果与命中率数据改完必须验证。我用一个简单的压测脚本构造 10 万个请求其中 9 万个是不存在的随机 ID1 万个是真实存在的 ID。改造前后的数据对比指标改造前改造后数据库查询次数约 10 万次约 1.1 万次缓存命中率约 10%约 89%平均响应时间320 ms45 ms数据库峰值 QPS约 1800约 200数据库查询次数从 10 万降到 1.1 万降幅接近 90%其中布隆过滤器挡掉了绝大部分无效请求缓存切面则让真实请求的重复查询命中缓存。剩下那 1000 次左右的额外查询就是布隆过滤器 1% 误判率放过的无效请求完全在预期内。响应时间从 320ms 降到 45ms用户侧感知非常明显。提示压测时记得把日志级别调高否则大量log.warn会拖慢性能测出来的数据不准。我第一轮压测就吃了这个亏关掉拦截日志后 QPS 才恢复正常。6. 常见问题与排查技巧实录6.1 布隆过滤器相关的高频坑坑一明明写入了却查不到。最常见的原因是 Funnel 类型不匹配。商品 ID 是 Long如果误用了Funnels.stringFunnel写入和查询时的哈希计算方式不一致结果就是永远返回 false。排查方法很简单写一个单元测试put一个值后立刻mightContain返回 false 就说明类型或漏斗配置有问题。坑二重启后过滤器为空。布隆过滤器是内存对象应用重启就没了如果预热逻辑没跑或跑失败所有请求都会被判定为不存在。排查时先看启动日志里有没有预热完成的输出没有就检查ApplicationRunner是否被正确注册、Mapper 查询是否抛异常被吞掉。坑三新增商品查不到。数据库加了新商品但没同步put进过滤器新商品会被拦截。这个要在商品新增的 Service 方法里显式调用bloomFilter.put(id)并且放在事务提交之后执行避免事务回滚了但过滤器已经写入的脏数据问题。6.2 缓存切面的典型异常异常一key 拼出来是对象地址。前面提过方法参数是对象时直接拼字符串会得到Product1a2b3c这种每次请求 key 都不同缓存永远不命中。解决办法是在buildKey里判断参数类型对象类型反射取getId。我封装了一个resolveKeyValue方法统一处理。异常二反序列化类型转换失败。缓存里存的是 JSON取出来是LinkedHashMap直接强转成ProductDetailVO会抛ClassCastException。这是因为GenericJackson2JsonRedisSerializer默认不写入类型信息。解决办法是在序列化器里开启类型信息或者取出来后用ObjectMapper.convertValue手动转换。我选后者更可控。异常三空值标记和正常数据冲突。如果某个商品的真实返回值恰好是字符串__NULL__就会被误判为空。虽然概率极低但严谨起见我把标记值改成了一个不可能出现的 UUID 前缀字符串彻底杜绝冲突。6.3 问题速查表现象可能原因排查方向解决方式过滤器全部返回 falseFunnel 类型不匹配单元测试 put 后 mightContain改用对应类型的 Funnel重启后穿透严重预热未执行查启动日志检查 ApplicationRunner 注册新商品查不到未同步写入过滤器查新增接口代码事务提交后 put缓存永不命中key 含对象地址打印实际 key反射取 ID 拼 key取缓存类型转换异常JSON 反序列化丢类型看缓存原始值ObjectMapper 手动转换空值缓存长期不失效过期时间配置错误查注解参数调小 nullExpireSeconds6.4 几条压箱底的实操心得第一条布隆过滤器的预估数据量要留余量。我一开始按当前商品数 80 万设的预估值结果业务增长快三个月就逼近上限误判率开始上升。后来改成按预估量的 1.5 倍设置给增长留空间。误判率上升的表现是数据库 QPS 缓慢爬升不容易察觉要定期监控。第二条缓存切面不要拦截事务方法。如果被注解的方法本身带Transactional切面的缓存写入可能发生在事务提交之前一旦事务回滚缓存里就留下了脏数据。我的做法是缓存注解只加在查询方法上写操作单独处理缓存失效职责分离更清晰。第三条空值缓存的过期时间要短于正常数据。正常商品详情缓存 5 分钟没问题但空值如果也缓存 5 分钟数据库新增数据后用户要等 5 分钟才能查到体验很差。我把空值设成 60 秒兼顾防穿透和及时性。第四条压测和线上要区分日志级别。布隆过滤器拦截日志在压测时会成为性能瓶颈线上又需要它来观察拦截效果。我的处理是用条件日志只在采样率命中时打印既保留可观测性又不拖性能。这套组合拳跑下来模拟商城的商品查询链路算是稳住了。布隆过滤器负责挡缓存切面负责管两者配合把数据库从无效请求里解放出来。后续如果数据量继续涨可以考虑把布隆过滤器换成 Redis 位图实现多实例共享或者引入布谷鸟过滤器支持删除但那是另一个话题了。就目前这个规模Guava 加切面的方案简单、够用、好维护我个人在实际项目里也更倾向于这种不过度设计的落地方式。
