压测缓存穿透关键在于验证防护策略有效性：需用明确不存在的key（如负数、超大ID）触发穿透逻辑，确保布隆过滤器校验、空值缓存等组件真实生效，并监控Redis内存、BF命中率、DB查询量及过期key计数四项指标。
压测缓存穿透，核心不是“能不能扛住”，而是“防护策略是否真生效”——空值缓存会不会被恶意ID打爆内存？布隆过滤器误判率是否在业务容忍线内？JMeter 本身不解决逻辑问题，但能暴露你代码里没想清楚的边界。
为什么不能直接用JMeter发随机key压Redis
因为真实穿透攻击不是“随机key”，而是“已知不存在的key”；而JMeter默认CSV或计数器生成的ID，大概率和你数据库/布隆过滤器里的合法ID空间重叠，结果测出来全是缓存命中，完全无效。
- 现象：JMeter报告QPS很高、Redis hit率99%，但DB QPS也同步飙升——说明请求根本没走通“穿透拦截”路径，可能连布隆过滤器都没调用
- 关键点：必须让JMeter生成的key明确落在“合法ID集合之外”，比如全负数、超长字符串、带特殊字符的ID（如
user:-9999999、user:abc!@#） - 更稳妥做法：提前导出10万条真实不存在的ID（例如DB中ID最大为100万，就取1000001~1100000），喂给JMeter的CSV Data Set Config，确保每条请求都触发穿透逻辑
JMeter中模拟穿透流量的3个实操要点
重点不在并发数，而在“请求特征是否触发防护链路”。以下配置直接影响压测结论可信度：
- 使用
JSR223 PreProcessor动态拼接key，避免硬编码。例如：vars.put("key", "user:" + (ThreadLocalRandom.current().nextInt(-1000000, -1))); - HTTP请求里必须包含对布隆过滤器的校验调用（如
BF.EXISTS bloom_user ${key}），不能只测GET ${key}—— 否则等于绕过第一道防线 - 监听器至少启用三个：
View Results Tree（查单条失败原因）、Aggregate Report（看整体DB QPS增幅）、Backend Listener接入Prometheus（观察Redis内存增长速率，判断空值缓存是否失控）
压测时必须监控的4个指标，缺一不可
只看响应时间或错误率会漏掉致命问题。比如布隆过滤器误判率1%，在5万RPS下就是500次/秒的无效DB查询——系统看似正常，实则已在雪崩边缘。
-
redis_memory_used_bytes增速：若空值缓存方案下该值每分钟涨超50MB，说明TTL设置过长或key空间不可控 -
bf.mexists返回0的比例：应稳定在95%以上，否则布隆过滤器加载不全或容量不足（capacity小于实际合法key总数） - DB的
Com_select增量：穿透防护有效时，该值在压测期间应趋近于0；若持续上升，检查代码中是否漏了BF.EXISTS判断分支 - Redis
expired_keys计数器：空值缓存方案中，该值应与请求QPS基本一致（比如压测1k RPS，expired_keys每秒增加≈1k），否则TTL未生效或被覆盖
真正难的不是跑出压测数据，而是理解每个数字背后对应的防护组件状态。比如 bf.mexists 命中率突然跌到80%，大概率是布隆过滤器没做持久化，服务重启后为空——这种细节，JMeter跑再多次也不会自动告诉你。
