彭贤踩坑实录：手写实现缓存穿透拦截，QPS从5k飙到50k

上周二凌晨三点，监控告警炸了。订单服务CPU飙到98%，DB连接池耗尽，直接宕机。排查发现，前端有个恶意脚本在疯狂请求不存在的商品ID，导致缓存全部穿透，请求全打在MySQL上。

更离谱的是，这次故障暴露了一个老问题：版本升级后 API 全变了。我们上个月刚把缓存中间件从旧版升到新版，原来的@Cacheable注解行为变了，拦截逻辑失效了。为了快速止血，彭贤没走常规的配置修复，而是决定手写实现一套底层的拦截器，直接挂在Filter层，把脏数据挡在缓存之前。

这篇就复盘彭贤这次救火的全过程。不聊虚的，直接上代码、上数据、上坑点。如果你也遇到过“升级即炸机”的情况，看看这篇怎么破。

性能瓶颈：为什么旧方案扛不住恶意流量

先看现场。故障发生前，我们的商品详情接口QPS稳定在3000左右，P99延迟80ms。恶意流量进来后，QPS瞬间冲到5000，但P99直接飙到2000ms+。

问题出在哪？

旧版缓存中间件的拦截逻辑是“先查缓存，miss后查DB，再写缓存”。这有个致命缺陷：不存在的Key也会触发DB查询。

我们之前做过压测，正常Key的缓存命中率是99.5%。但恶意流量全是随机生成的无效ID，缓存命中率直接归零。5000 QPS全打DB，MySQL扛不住是必然的。

更坑的是，新版中间件改动了拦截器的执行顺序。旧版是Filter -> CacheInterceptor -> Controller，新版变成了Filter -> SecurityFilter -> CacheInterceptor。中间插了个权限校验，导致无效ID的请求也要先走一遍鉴权逻辑，CPU白白消耗在正则匹配和Token解析上。

彭贤当时说：“别纠结配置了，新版API变动太大，文档都没更新完。直接手写一个轻量拦截器，放在最前面，把无效ID拦下来。”

这个思路很对。与其跟框架的变动死磕，不如手写实现一个确定性的拦截层，逻辑简单、可控性强。

优化前代码：被废弃的注解与失效的拦截

先看优化前的代码，这是典型的“框架依赖症”。

// 优化前：依赖框架注解，行为不可控
@RestController
@RequestMapping("/api/product")
public class ProductController {@Autowiredprivate ProductService productService;// 旧版注解，升级后行为变化@Cacheable(value = "product", key = "#id", unless = "#result == null")public ProductDTO getProductDetail(Long id) {return productService.findById(id);}
}

这段代码的问题有三点：

注解粒度太粗：@Cacheable只处理了“有值”的情况，没处理“查了DB发现不存在”的情况。
异常处理缺失：如果DB查询抛异常，缓存不会被写入，下次请求还是打DB。
无前置拦截：所有请求都要进到Controller，经过Spring MVC的完整链路，开销大。

更关键的是，新版中间件的@Cacheable实现里，key的生成逻辑变了。旧版是"product:" + id，新版变成了"product:v2:" + id + ":" + userId。这导致新旧版本的缓存Key完全不兼容，升级后缓存命中率瞬间归零，全量回源DB。

这就是“版本升级后 API 全变了”的惨烈后果。框架的黑盒逻辑一旦变化，你的业务代码就失去了控制力。

优化方案与代码：手写实现拦截器与布隆过滤器

彭贤的方案很直接：手写实现一个InvalidIdInterceptor，放在Filter链的最前面，用布隆过滤器（Bloom Filter）快速判断ID是否可能存在。

思路是这样的：

启动时加载：把当前所有有效商品ID加载进布隆过滤器。
请求拦截：每个请求进来，先用布隆过滤器判断ID是否存在。
快速失败：如果布隆过滤器说“不存在”，直接返回404，不往后走。
概率容忍：布隆过滤器有极低的误判率（比如1%），但这1%的请求会正常走缓存和DB，对系统影响微乎其微。

代码实现如下：

// 优化后：手写实现拦截器 + 布隆过滤器
@Component
public class InvalidIdInterceptor implements HandlerInterceptor {private final BloomFilter<Long> bloomFilter;// 构造函数注入，启动时初始化public InvalidIdInterceptor(ProductRepository repository) {// 假设商品总量100万，误判率0.1%this.bloomFilter = new BloomFilter<>(1_000_000, 0.001);List<Long> allIds = repository.findAllIds();allIds.forEach(bloomFilter::add);}@Overridepublic boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {// 只拦截商品详情接口if (!request.getRequestURI().startsWith("/api/product/detail/")) {return true;}// 提取IDString path = request.getRequestURI();String idStr = path.substring(path.lastIndexOf("/") + 1);// 快速校验：非数字直接拦截if (!idStr.matches("^\\d+$")) {response.setStatus(HttpServletResponse.SC_BAD_REQUEST);response.getWriter().write("Invalid ID");return false;}Long id = Long.parseLong(idStr);// 布隆过滤器判断if (!bloomFilter.mightContain(id)) {// 大概率不存在，直接返回404response.setStatus(HttpServletResponse.SC_NOT_FOUND);response.getWriter().write("Product not found");return false;}// 通过拦截，继续走后续逻辑return true;}
}

这段代码有几个关键点值得细说：

1. 为什么用布隆过滤器？

布隆过滤器的空间复杂度极低。100万个ID，误判率0.1%，只需要约1.2MB内存。相比把100万个ID存进HashSet（需要约8MB内存），节省了大量堆空间。而且判断速度是O(1)，比HashMap快一个数量级。

2. 误判率怎么定？

0.1%是个平衡点。太高会导致正常请求被误杀，太低会增加内存占用。我们根据商品总量和可接受的错误率，用BloomFilter的构造函数自动计算了位数组大小。

3. 为什么放在Filter而不是AOP？

Filter在Servlet容器层执行，比Spring的AOP更靠前。AOP要等Spring上下文初始化完成，Filter可以在更早的阶段拦截。对于高频接口，这点差异在极端流量下会放大。

4. 布隆过滤器怎么更新？

布隆过滤器不支持删除。所以我们在商品新增时，需要动态更新过滤器。这里有个坑：如果直接用bloomFilter.add(newId)，多线程环境下会有并发问题。

彭贤的处理方式是：用ConcurrentBloomFilter，底层用了分段锁。虽然有一定开销，但商品新增的频率远低于查询，这点开销可以接受。

另外，为了应对商品下架的场景，我们加了一个“黑名单”机制。下架的商品ID会加进一个ConcurrentHashSet，拦截器里先查黑名单，再查布隆过滤器。这样既能快速拦截无效ID，又能处理下架商品。

对比数据：QPS翻10倍，P99降90%

优化上线后，我们做了三轮压测。数据说话：

指标	优化前	优化后	变化
QPS（恶意流量）	5,000	50,000	10倍
P99延迟	2,000ms	150ms	92.5%
CPU使用率	98%	35%	64%
DB QPS	5,000	200	96%
内存占用	1.2GB	1.3GB	+8%

几个关键观察：

DB压力骤降：优化前，5000 QPS全打DB。优化后，99%的恶意请求被拦截在Filter层，DB只收到200 QPS的正常请求。DB从“救命状态”回到“舒适区”。
P99延迟稳定：优化前P99是2000ms，优化后150ms。这是因为无效请求不再进入业务逻辑，避免了线程池阻塞和DB等待。
内存微增：布隆过滤器+黑名单占了约100MB内存，相比总内存1.2GB，占比8%。这个代价可以接受。
CPU下降明显：从98%降到35%。主要省在两个方面：一是无效请求不再走Spring MVC完整链路，二是DB查询减少，应用层等待DB的时间大幅缩短。

彭贤还特别提到，这次优化后，我们甚至没加服务器，直接扛住了之前10倍的流量。这就是手写实现带来的确定性收益：你清楚每一行代码在做什么，性能瓶颈在哪里，怎么调优。