解读

1. 面试官想确认你是否能把“布隆过滤器误判”这一概率事件量化到压测指标里，而不是停留在“误判率很低”这种定性描述。
2. 国内互联网场景下，缓存穿透往往伴随高并发读，误判带来的额外回源量会直接放大后端压力，压测必须给出可接受的回源增长上限。
3. 需要给出“误判率→回源QPS放大系数→后端CPU/RT/错误率”的完整推导，并说明如何在压测脚本里注入误判流量，最终判断当前布隆过滤器参数是否满足SLA。

知识点

1. 布隆过滤器基础：k个哈希函数、m位数组、n个已存键，误判率 p ≈ (1 – e^(-kn/m))^k。
2. 回源放大系数：设业务读QPS为Q，命中缓存概率为h，布隆过滤器误判率为p，则回源QPS = Q·(1–h)·p。
3. 压测指标转化：回源QPS↑ → 后端RT↑ → 线程池耗尽 → 超时/错误率↑ → 可用性↓。需把“p”映射到“可用性”或“P99 RT”上的可接受增量。
4. 国内常用阈值：核心接口P99 RT增加不超过10 %，错误率不超过0.1 %；对应回源增长一般要求≤5 %。
5. 压测实现：
   a. 预热阶段把真实key灌入布隆过滤器；
   b. 构造“不存在key”流量占比α，让α·p·Q等于预期回源峰值；
   c. 用异步线程实时采集后端回源QPS、RT、CPU，与基线对比；
   d. 逐步提升Q，观察当回源QPS达到“Q·(1–h)·p”时是否突破SLA。
6. 调优闭环：若p过大，可增大m或k，但会增加内存及哈希CPU；需在压测里同时监控哈希耗时与内存占用，找到“误判率—资源”平衡点。

答案

第一步，计算理论误判率。根据线上key规模n、可用内存m，用公式 p ≈ (1 – e^(-kn/m))^k 求出p。
第二步，推导回源放大倍数。设缓存命中率h，则回源QPS放大倍数 = (1–h)·p。例如h=90 %，p=1 %，则每1万业务读会额外带来10个回源。
第三步，把放大倍数写进压测模型。在JMeter/PTS脚本里增加“不存在key”线程组，占比α=10 %，总目标Q=1万/s，则误判流量=1000/s，实际回源=1000·p。
第四步，设定SLA阈值。例如后端Java集群单实例极限回源QPS为500，误判带来的新增回源必须<25（5 %安全边际）。若p=1 %，则1000·p=10，满足；若p=3 %，则30>25，需调整。
第五步，执行阶梯负载。从50 %目标Q开始，每2分钟递增10 %，实时对比“布隆过滤器开启 vs 关闭”时的P99 RT、错误率、回源QPS。若RT增长>10 %或错误率>0.1 %，即判定当前p不可接受。
第六步，给出调优方案。若p超标，优先扩容m（内存换误判），其次再考虑k；每次调优后回归压测，直到在满足SLA的前提下内存增量<5 %、哈希CPU增量<3 %。
最终报告里用“误判率—回源QPS—RT/错误率”三张曲线图（文字描述即可）证明：当前p=0.8 %，对应回源增长4.2 %，P99 RT增长6 %，错误率0.05 %，满足核心接口SLA，布隆过滤器参数可上线。

拓展思考

1. 双层布隆：内存层用8 MB布隆过滤热key，SSD层再布隆一次，误判率相乘可降到10^-4，但两次哈希带来额外5 μs延迟，需在压测里用TP99链路追踪确认是否吃掉缓存集群10 % CPU。
2. 动态删除场景：如果业务允许key过期删除，普通布隆无法移除，可用Counting Bloom或RedisBloom的布谷过滤器，压测时要加入“删除+重新写入”脉冲流量，观察计数器溢出导致的误判跳升。
3. 大key热key叠加：当误判的回源key恰好是热key，会瞬间打满单台MySQL连接；压测脚本里需把“不存在key”与“热key”做正交实验，用染色标记确认是否出现“误判+热key”双重暴击。
4. 成本量化：每降低0.1 %误判率需增加1 GB内存，在阿里云8核32 G实例上月成本增加150元；压测报告里可把“RT收益/内存成本”算出ROI，供架构评审会拍板。