摸索布隆滤镜的“肉装”与“功能装”
布隆这玩意儿，大家都在用，但大部分人都是闭着眼睛抄代码，设参数。看着网上说K设成3，M设成多少，然后就照搬了。我以前也这样，觉得能跑就行，又不占多少资源。
但真正等到系统跑起来，流量一大，你就会发现问题来了。布隆滤镜这东西，它不是一个通用解，它就是个需要根据战场实时换装的英雄。你分不清什么是顺风什么是逆风，那肯定要吃大亏。
我花了一个多月时间，在本地搭了五个不同的Redis集群，用来模拟不同量级的业务场景，就是为了搞清楚，到底什么时候该堆“肉装”把容错率压到最低，什么时候该出“功能装”把速度和空间提到最高。
顺风局：堆满容错的“全肉装”
什么叫顺风局？很简单，就是资源敞开了用，流量低，或者说，你绝大部分请求都是能命中缓存的。这种时候，你追求的就是一个字：稳！
我模拟的第一个场景，就是咱们公司一个偏后台的业务，数据量大，但是QPS不高。这种时候，一旦出现误判（假阳性），虽然不会造成致命错误，但会多一次不必要的数据库查询，浪费宝贵的响应时间。我拿起参数就开始往死里调，目的就是要把假阳性概率控制在万分之一以下。
- 内存空间M： 直接拉到最大，能占地儿就占地儿。
- 哈希次数K： 直接上了7次甚至8次，把校验流程拉满。
我跑了一百万条数据进去，做了五轮查询测试，结果非常理想。容错率低到几乎可以忽略。这套配置就是典型的“肉装”——耗资源，但扛揍，极度稳定。缺点就是初始化慢，每次重构数据都要花不少时间。
逆风局：追求速度和效率的“功能装”
逆风局就完全反过来了。逆风局通常出现在咱们的核心业务线上，流量跟海啸一样，机器性能已经被压榨到极限。这时候，多给你一兆内存，多给你一毫秒响应时间，都可能救命。
我把测试切换到了咱们APP首页的推荐接口，那个QPS是后台业务的几十倍。按照刚才的“肉装”配置跑了一下，立马就崩了。Redis内存被打满了，CPU飙升，简直惨不忍睹。这时候，我就得换思路了。
我抓紧时间调整了参数，狠心把容错率放宽到千分之五，甚至千分之一。这意味着每查询一千次，可能有五次是误判，需要多跑一次查询。但换来的是内存占用的大幅降低和查询速度的提升。
- 内存空间M： 减半，能省则省。
- 哈希次数K： 降到3次，甚至2次。拼的就是速度。
这个“功能装”配置，就是牺牲了一点点准确性，换来了极高的运行效率。只有分清了顺风逆风，你才知道怎么调参数。但我能这么 obsessively（着魔般地）去研究这些细枝末节的配置，完全是被逼的。
我为什么要这么抠细节？
以前我真不是个抠细节的人，能跑就行。直到三年前，我还在上家公司做架构师。那会儿我们接了一个省级的大项目，老板信誓旦旦说给的资源足，让我们放开手脚用最好的配置。我当时觉得是顺风局，布隆滤镜参数都是怎么稳怎么来，内存拉满。
项目一上线，跑得好好的。但没想到，甲方那边突然加需求，数据量瞬间翻了十倍，我们的资源根本没跟上。系统直接进入了超级逆风局。
那天晚上，系统报警像鞭炮一样响，用户投诉电话打爆了。最要命的是，因为我们布隆滤镜占内存太多，导致核心接口的Redis Key被强制淘汰，直接导致生产环境出现了数据穿越和严重错乱。事情闹得很大，直接被省厅点名了。我连夜带着团队在机房里抢救，那压力大得，感觉头发都快掉光了。
虽然问题解决了，但那次事故把我的名声彻底搞臭了。我的年终奖被扣光，绩效也成了最低档。我当时就想不通，技术上明明没问题，怎么就栽在了一个小小的资源分配上？
我思考了一个星期，终于明白：这不是技术问题，是战略问题。我把逆风局当成了顺风局来打。这回失败，让我彻底离开了原来的公司，也让我下定决心，要把所有技术细节都研究透，从一个盲目自信的架构师，变成一个步步为营的实践者。
也就是在那之后，我才开始搭建这个实践分享博客。我现在分享的每一个配置，背后都是我当初交过的学费。兄弟们，别再无脑抄作业了，先分清你是顺风还是逆风！
