知识分享总结

布隆过滤器

作用

判断一定不在集合中（多个位，只要有1个位为0，则一定不在集合中）

判断可能在集合中（多个位都为1时，则可能在集合中，因为两个不同值的哈希结果可能一样）

应用场景

1、网页爬虫对 URL 去重，避免爬取相同的 URL 地址；
2、反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱；
3、Google Chrome 使用布隆过滤器识别恶意 URL；
4、Medium 使用布隆过滤器避免推荐给用户已经读过的文章；
5、Google BigTable，Apache HBbase 和 Apache Cassandra 使用布隆过滤器减少对不存在的行和列的查找。
6、布隆过滤器还有一个应用场景就是解决缓存穿透的问题。所谓的缓存穿透就是服务调用方每次都是查询不在缓存中的数据，这样每次服务调用都会到数据库中进行查询，如果这类请求比较多的话，就会导致数据库压力增大，这样缓存就失去了意义。利用布隆过滤器我们可以预先把数据查询的主键，比如用户 ID 或文章 ID 缓存到过滤器中。当根据 ID 进行数据查询的时候，我们先判断该 ID 是否存在，若存在的话，则进行下一步处理。若不存在的话，直接返回，这样就不会触发后续的数据库查询。需要注意的是缓存穿透不能完全解决，我们只能将其控制在一个可以容忍的范围内。

在Redis中，主要是处理无效的穿透流量，对于穿透的流量，有两种方案：
1。DB查询后， 如果没数据，在redis中写个空的标记，并设置过期时间
2。在进入DB查询前，查询一次过滤器，没数据就直接返回空

方案1， 正常情况下没有问题，因为偶尔的无效请求可能没有那么多，DB也还能承受，redis空间也足够；
但是当有人恶意请求你的接口时， DB会很快撑不住，redis也会很快空间不足，这时如果有个布隆过滤器，那么它就可以用很小的时间、空间代价， 过滤掉很大一部分无效请求，保证对DB的实际查询保持在一个正常QPS

正常的query， 查询redis， 再查DB
bloom filter方式， 查询redis， 再redis bloom 查询是否为有效查询， 再查询DB

1.当有大量穿透查询的场景下， redis bloom的查询成本比DB的成本低很多， 能支撑的QPS更高。可以最大程度的保护DB。
2.如果是单机部署场景下， 可以考虑内存，但是要考虑宕机或者重新部署时， bloom filter没了， 要重新构建的问题。
3.bloom filter 的核心优势就是内存消耗低， 1000万的数据， 采用google guava的hash计算方式， 在0.001的误差范围内， 消耗内存在10MB左右， 完全可以接受。
4.分布式环境下，数据放到内存中来处理， 属于典型的local cache 问题；如果想要保持一致性， 可以通过数据变更时， 群发MQ消息的方式让应用服务器实例更新。 我觉得这个方案在数据变更频次很低而访接口QPS极高时， 可以尝试。否则，当有实例 bloom filter数据未更新时， 在未更新这个间隔内， 用户请求路由到不同实例， 就会出现一下能查到，一下查不到奇怪现象。
5.接4， 如果数据变更频次很低时， 也可以考虑把bloom fliter 数据写到配置中心里， 让配置中心把数据推送到应用实例上。

参考：

详解布隆过滤器的原理，使用场景和注意事项 - 知乎

布隆过滤器-原理、时间复杂度、空间复杂度、不支持删除_二十六画生的博客的博客-CSDN博客_布隆过滤器的时间复杂度