Hash Table 的弊端
在日常生活中，包括在设计计算机软件时，我们经常要判断一个元素是否在一个集合中。比如：
- 在字处理软件中，需要检查一个英语单词是否拼写正确（也就是要判断它是否在已知的字典中）
- 在 FBI，一个嫌疑人的名字是否已经在嫌疑名单上
- 在网络爬虫里，一个网址是否被访问过等等
- yahoo，gmail 等邮箱垃圾邮件过滤功能
最直接的方法就是将集合中全部的元素存在计算机中，遇到一个新元素时，将它和集合中的元素直接比较即可。一般来讲，计算机中的集合是用哈希表（Hash Table）来存储的。它的好处是快速准确，缺点是费存储空间。当集合比较小时，这个问题不显著，但是当集合巨大时，哈希表存储效率低的问题就显现出来了。
例如在需要处理 10 亿个黑名单邮件地址列表的场景下，没有邮件地址需要 8 个字节的信息指纹，即需要 8GB 内存，为了减少 Hash 冲突，还需要一定的 Hash 空间冗余，假如空间利用率为 50%，则需要 16GB 的内存空间。
布隆过滤器
在对过滤要求不完全精确的场景下，可用布隆过滤器代替 Hash 表。布隆过滤器通过一个二进制列表和一组随机数映射函数实现
仍以需要处理 10 亿邮件地址黑名单列表为例，在内存中建立一个 2GB 大小的存储空间，即 16G 个二进制 bit，并全部初始化为 0。要将一个邮箱地址加入黑名单时，使用 8 个随机映射函数（F1, F2, ..., F8） 对这个地址产生 0 ~ 16G 范围内的 8 个信息指纹（随机数），从而将该邮箱地址映射到 16G 二进制存储空间的 8 个位置上，然后将这些位置置为 1。当要检查一个邮箱地址是否在黑名单中时，使用同样的映射函数，得到 16G 空间 8 个位置的 bit，如果这些值都为 1，那么布隆过滤器认为该邮箱地址在黑名单中
可以看到，处理同样数量的信息，布隆过滤器只要 Hash 表所需内存的 1/8。但是布隆过滤器可能导致误判。因为一个邮箱地址映射的 8 个 bit 可能正好都被其他邮箱地址设为 1 了。但是这种可能性很小（上面的例子中，在误识概率在万分之一以下），通常在系统可接受范围内。如果需要精确的判断，则不适合使用布隆过滤器
应用
可以快速且空间效率高的判断一个元素是否属于一个集合；用来实现数据字典，或者集合求交集。
Google chrome 浏览器使用 bloom filter 识别恶意链接（能够用较少的存储空间表示较大的数据集合，简单的想就是把每一个URL都可以映射成为一个bit），并且误判率在万分之一以下
再如此题：
A, B 两个文件，各存放 50 亿条 URL，每条 URL 占用 64 字节，内存限制是 4G，让你找出 A, B 文件共同的 URL。如果是三个乃至 n 个文件呢？
分析 ：如果允许有一定的错误率，可以使用 Bloom filter，4G 内存大概可以表示 40 亿 bit。将其中一个文件中的 url 使用 Bloom filter 映射为这 40 亿 bit，然后挨个读取另外一个文件的 url，检查是否与 Bloom filter，如果是，那么该 url 应该是共同的 url（注意会有一定的错误率）
布隆过滤器缺点
布隆过滤器的好处在于快速，省空间。但是有一定的误识别率。随着存入的元素数量增加，误算率随之增加。但是如果元素数量太少，则使用散列表足矣。常见的补救办法是在建立一个小的白名单，存储那些可能别误判的信息
另外，一般情况下不能从布隆过滤器中删除元素. 我们很容易想到把位数组变成整数数组，每插入一个元素相应的计数器加 1，这样删除元素时将计数器减掉就可以了。然而要保证安全地删除元素并非如此简单。首先我们必须保证删除的元素的确在布隆过滤器里面。这一点单凭这个过滤器是无法保证的
