缓存命中率持续低于90%是缓存穿透的首要信号，表现为keyspace_hits/(keyspace_hits+keyspace_misses)长期偏低、keyspace_misses中80%以上为不存在的key，且数据库空查询qps突增。
缓存命中率持续低于90%就是第一个红灯
缓存穿透最直接的表现不是错误，而是缓存“变懒了”——大量请求根本没进缓存就直奔数据库。所以第一反应不是查日志，而是看 keyspace_hits 和 keyspace_misses 这两个指标。用 INFO stats 命令就能拿到：
- 命中率 =
keyspace_hits / (keyspace_hits + keyspace_misses) - 如果这个值长期低于 90%，且
keyspace_misses持续上涨，基本可以锁定穿透风险 - 特别注意：单次低命中率可能是偶发抖动，要结合时间窗口（比如连续5分钟）观察趋势
数据库返回 null 的 QPS 突增必须人工确认
缓存层不拦人，数据库得扛住。但真正危险的信号是：数据库里同一类查询（比如 SELECT * FROM user WHERE id = ?）返回空结果的频次突然飙升。这说明请求在“合法格式”下疯狂试探不存在的数据。
- 不要只看总 QPS，要拆解
SELECT语句的空结果占比（例如用 MySQL 的慢日志或代理层埋点统计） - 如果某类 ID 查询（如
user_id）空响应占比超过 30%，且对应 Redis key 全部未命中，大概率是穿透 - 警惕
id=-1、id=999999999这类明显越界的参数——它们往往不会触发业务校验，却能绕过布隆过滤器
布隆过滤器拦截次数为 0 或骤降说明它没生效
如果你已经上了布隆过滤器，但它没起作用，那等于白加。关键要看 BF.EXISTS 被调用后返回 0（不存在）的次数是否与预期匹配。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redis-cli --scan --pattern "product_bf:*"确认布隆过滤器 key 是否真实存在并已初始化 - 检查代码里是否漏掉了
BF.ADD—— 比如预热脚本没跑、新增数据没同步写入过滤器 - 误判率设太高（如
errorRate=0.1）会导致大量“假存在”，让无效请求继续穿透；建议生产环境控制在0.01以内 - 注意：布隆过滤器不支持删除，如果业务有删数据场景，得换
CountingBloomFilter或配合其他方案
日志里高频出现 “cache miss → db null” 链路就是穿透证据
在应用层打点时，别只记“缓存未命中”，要明确标记后续 DB 查询结果。一条完整链路日志应该包含：cache_miss → db_query → db_result_null。
- 用 ELK 或 Loki 聚合这类日志，按
key字段分组统计，能快速发现高频穿透 key（比如user:1234567890出现上千次） - 如果某个 key 的
db_result_null次数远高于其在布隆过滤器中的存在概率（比如 BF 说“可能存在”，但实际查了 100 次全是 null），说明该 key 是恶意构造的“漏网之鱼” - 注意：日志采样率别设太高，否则影响性能；也别太低，否则漏掉关键 pattern
布隆过滤器和空值缓存不是开了就万事大吉，真正难的是把监控指标和业务语义对齐——比如“空结果 QPS”得区分是用户手误输错 ID，还是攻击者在暴力枚举。这点不厘清，再准的指标也只是噪音。
