Bloom Filter是由Bloom在1970年提出的一种多哈希函数映射的快速查找算法。通常应用在一些需要快速判断某个元素是否属于集合，但是并不严格要求100%正确的场合。

 一. 场景 

　　为了说明Bloom Filter存在的重要意义，举一个实例：

　　假设要你写一个网络蜘蛛（web crawler）。由于网络间的链接错综复杂，蜘蛛在网络间爬行很可能会形成“环”。为了避免形成“环”，就需要知道蜘蛛已经访问过那些URL。给一个URL，怎样知道蜘蛛是否已经访问过呢？稍微想想，就会有如下几种方案：

　　1. 将访问过的URL保存到数据库。

　　2. 用HashSet将访问过的URL保存起来。那只需接近O(1)的代价就可以查到一个URL是否被访问过了。

　　3. URL经过MD5或SHA-1等单向哈希后再保存到HashSet或数据库。

　　4. Bit-Map方法。建立一个BitSet，将每个URL经过一个哈希函数映射到某一位。

　　方法1~3都是将访问过的URL完整保存，方法4则只标记URL的一个映射位。

　　以上方法在数据量较小的情况下都能完美解决问题，但是当数据量变得非常庞大时问题就来了。

　　方法1的缺点：数据量变得非常庞大后关系型数据库查询的效率会变得很低。而且每来一个URL就启动一次数据库查询是不是太小题大做了？

　　方法2的缺点：太消耗内存。随着URL的增多，占用的内存会越来越多。就算只有1亿个URL，每个URL只算50个字符，就需要5GB内存。

　　方法3：由于字符串经过MD5处理后的信息摘要长度只有128Bit，SHA-1处理后也只有160Bit，因此方法3比方法2节省了好几倍的内存。

　　方法4消耗内存是相对较少的，但缺点是单一哈希函数发生冲突的概率太高。还记得数据结构课上学过的Hash表冲突的各种解决方法么？若要降低冲突发生的概率到1%，就要将BitSet的长度设置为URL个数的100倍。

　　实质上上面的算法都忽略了一个重要的隐含条件：允许小概率的出错，不一定要100%准确！也就是说少量url实际上没有没网络蜘蛛访问，而将它们错判为已访问的代价是很小的——大不了少抓几个网页呗。

二. Bloom Filter的算法 

 　　废话说到这里，下面引入本篇的主角——Bloom Filter。其实上面方法4的思想已经很接近Bloom Filter了。方法四的致命缺点是冲突概率高，为了降低冲突的概念，Bloom Filter使用了多个哈希函数，而不是一个。

   　Bloom Filter算法如下：

          集合数据结构一般都有这么一个方法：contains。其作用就是判断给定的元素是否存在集合中，这是一个常用的方法。其最简单的内部实现即遍历集合内的元素，一个个的判断是否与给定元素相等。为了更高效点我们甚至可以采用“更好的（好是相对的）”算法实现。比如如果该集合是已经排序的，那么我们用二分查找来实现contains肯定更好。但是，如果集合的数据量庞大到一定程度，大部分我们熟知的算法不再有什么用了。即使可以使用，但是机器内存也不允许。

而Bloom Filter就是这么一个空间利用率非常高的算法。我们先来看看这个算法的原理：

实例：

1 首先我们有一个长度为n的比特数组，开始的时候将这个比特数组里所有的元素都初始化为0

00000000000000000000

上面的比特数组n为20

2 然后选取k个哈希函数，这k个哈希函数产生的结果的值的范围在0到n-1之间（对于上面的比特数组，即0到19） 。对每个要添加进集合的对象进行哈希运算，然后将哈希计算结果作为数组的索引，将索引位置的比特位设置为1（不管该比特位原先为0还是为1）。

比如我们选取三个哈希函数，对于对象A哈希值为0，5，7。那么比特数组就为：

10000101000000000000

对象B的值为2，8，13，那么添加B后的比特数组为：

10100101100001000000

对象C为0，4，7（对象C的第一个哈希函数的值与对象A的相同了，没关系我们还是设置为1就可以了）：

10101101100001000000

现在我们的Bloom Filter里已经有3个元素了。现在我们要判断某元素X是否在该集合中。就相当于我们要实现一个contains方法。那么这个方法如何实现呢？

对元素X采用相同的三个哈希函数哈希，然后以这三个哈希值为索引去比特数组里找。如果三个索引位置的比特位都为1我们就认为该元素在集合中，否则不是。

我们可以用伪代码简单的描述一下这个算法：

public class BloomFilter{
    private bit[] bitSet = new bit[N];

    public void add(Object element){
      int[] hashValues = getHashValues(element);
      for(int i : hashValues){
         bitSet[i] = 1;
      }
    }

    public boolean contains(Object element){
        int[] hashValues = getHashValues(element);
        for(int i : hashValues){
           if(bitSet[i] != 1) return false;
        }
        return true;
    }

 

}

算法还是挺直观的，对不。想想，一个很大的对象，经过一哈希，然后就变成了Bloom Filter里面的一个比特，这个空间利用效率是多么高啊。如果哈希函数的实现效率也很高的话那么不仅空间利用率高，时间复杂度也低啊。这真是一个神奇的算法对吧。

可能你想，以后我就把我们那个啥数组的contains方法替换成Bloom Filter的实现吧。

不过你仔细验证过这个算法没，它存在一些问题。这个算法有以下这么几个特征：

1 如果该元素真的在集合中，那么Bloom Filter的contains方法肯定会返回true，这就是Bloom Filter不会漏报的特性。

2 如果该元素不在集合中，但Bloom Filter的contains方法有可能返回true。因为不同的元素经过哈希之后哈希值可能发生碰撞。这是Bloom Filter有可能误报的特性。但是这个误报的几率并不高。

根据这两个特性Bloom Filter在大量数据时还是挺有用的。比如假设我们有一个缓存服务器集群，集群里的不同的服务器承担的缓存也不尽相同。如果一个用户请求过来了，我们如何能快速的判断出用户请求的这个url在集群里哪台服务器上呢？因为每台服务器上缓存的url对应的页面非常庞大，我们全部弄到内存里代价也很高。我们就可以在每台服务器上放一个Bloom Filter，里面添加的都是本服务器上有缓存的那些url。这样即使Bloom Filter误报了，那就是把一个url发到了一个并不持有该url对应的缓存的服务器上，结果就是缓存未命中，缓存服务器只需要将该url打到后端的上游服务器就好了。

根据Bloom Filter的特征我们可以看到不是所有的场景都可以用的，只有在一些能容许少量的误报的情况下使用才行。该算法用很低的误报率却换来了大量的存储空间，实在是是一个很巧妙的算法。 

三. Bloom Filter参数选择 

 (1)哈希函数选择

   　　哈希函数的选择对性能的影响应该是很大的，一个好的哈希函数要能近似等概率的将字符串映射到各个Bit。选择k个不同的哈希函数比较麻烦，一种简单的方法是选择一个哈希函数，然后送入k个不同的参数。

 (2)Bit数组大小选择 

   　　哈希函数个数k、位数组大小m、加入的字符串数量n的关系可以参考参考文献1。该文献证明了对于给定的m、n，当 k = ln(2)* m/n 时出错的概率是最小的。

   　　同时该文献还给出特定的k，m，n的出错概率。例如：根据参考文献1，哈希函数个数k取10，位数组大小m设为字符串个数n的20倍时，false positive发生的概率是0.0000889 ，这个概率基本能满足网络爬虫的需求了。

 Bloom Filter算法：http://en.wikipedia.org/wiki/Bloom_filter