布隆过滤器(BloomFilter)——应用(三)

布隆过滤器(BloomFilter)——应用(三)

1. 分布式爬虫

• 简介
  • 大型爬虫项目一般会采用分布式架构，以多个节点协作的方式进行，以达到快速、高效地爬取海量网页数据的目的。要进行协作，那就需要一个分布式中间件，用于相互通知。分布式爬虫项目一般将已经爬取的网址存储与中间件中，用于告知其他节点该网址已经被爬取过。常见的分布式爬虫框架，例如像Scrapy-Redis，就是如此。
• 存在的问题
  • 为了快速判断网址是否已经被爬取，以便继续快速爬取数据，我们采用了内存数据库Redis。但是，如果爬取的是海量网址的数据，那么存于Redis的已爬取的网址会越来越多，而内存容量又比较有限，最终会导致内存容量不够。
• 解决方案
  • 在Redis中安装BloomFilter插件，将已爬取的网址存于其中，每次爬取时判断网址是否存在于BloomFilter中。这样，将会大大降低内存使用量，同时会存在一定误判率（由initial_size和error_rate调整，这部分网址可以忽略，或者由后续反馈添加）
• 简易的代码示例

  // 注意，请先安装BloomFilter插件
  // 除了引入Redis的jar包外，还需引入com.redislabs jrebloom
  
  Client client = new Client(jedisPool);
  
  // 创建一个BloomFilter
  // arg2: 10000为容量，需根据自己的业务调整 
  // arg3: 0.1%为错误率
  client.createFilter("my_filter", 10000, 0.001);
  
  String content = "http://www.baidu.com";
  // 向BloomFilter添加元素
  client.add("my_filter", content);
  
  // 判断BlooFilter中是否存在该元素
  boolean res = client.exists("my_filter", content);
  
  jedisPool.close();
  

2. 大型NoSQL数据库

• 简介
  • 大型NoSQL数据库为了快速读/写和容纳海量数据，一般会采用分布式架构（例如中心化的HBase、去中心化的Cassandra）。因为客户端的频繁请求以及分布式架构内部的复杂性，会存在大量的I/O传输。
• 存在的问题
  • 如果一次查询请求，直接让所有节点开始查询。这样，每次任意一个请求都会导致整个集群I/O大量上升，从而影响集群性能。
• 解决方案
  • 例如HBase，会为每个表的rowkey维护一个BloomFilter。在一次get请求中，首先会判断Memstore，再判断BlockCache，最后判断对应HFile文件当中的BloomFilter中是否存在该get请求的rowkey。如果不存在，那么返回查不到该rowkey（前面讲过BloomFilter的性质，如果BloomFilter返回false，那么肯定不存在）；如果存在，那么就继续扫描HFile（速度慢，当然还是可能不存在）。这样，通过BloomFilter的判断可以减少大量读取HFile的I/O消耗。
• 简易示意图
  

3. 电子邮件过滤

• 简介
  • 电子邮件每日在网络的传输数量是海量的，但是其中存在大量的垃圾邮件，需要进行排除。一般第一步的做法是采用“朴素贝叶斯”方案来判断邮件是否是垃圾邮件，进行过滤，另外要针对经常发送大量垃圾邮件的地址整理出一个黑名单，进行过滤。
• 存在的问题
  • 垃圾邮件的发送者通常会注册多个邮件地址，或者一个被拉黑后还会再次注册另一个邮件地址，这样的话会导致这个黑名单急剧增大（通常至少会有数亿），而维护这样一个数量庞大的黑名单是很占资源的，随着黑名单的增大，内存就会越来越不够用。
• 解决方案
  • 一般这种情况，我们可以将黑名单中所有的地址存入BloomFilter中，以减小内存占用。当一个地址发送邮件的时候，会判断地址是否存在BloomFilter中。如果不存在，那么可以放行；如果存在，那么很可能是恶意的邮件地址，这个时候你还需要维护一个小型的被误判的地址的白名单（可由自己测试以及用户反馈生成），针对这部分地址进行放行，对其余地址进行阻拦。
• 简易示意图
  

4. Web 缓存穿透

• 这个就不多说了，网上例子太多了^_^