一、什么情況下需要布隆過濾器？
1、先來看幾個比較常見的例子：
- 字處理軟件中，需要檢查一個英語單詞是否拼寫正確
- 在 FBI，一個嫌疑人的名字是否已經在嫌疑名單上
- 在網絡爬蟲里，一個網址是否被訪問過
- yahoo, gmail 等郵箱垃圾郵件過濾功能
這幾個例子有一個共同的特點： 如何判斷一個元素是否存在一個集合中？
2、常規思路：
- 數組
- 鏈表
- 樹、平衡二叉樹、Trie
- Map (紅黑樹)
- 哈希表
雖然上面描述的這幾種數據結構配合常見的排序、二分搜索可以快速高效的處理絕大部分判斷元素是否存在集合中的需求。但是當集合里面的元素數量足夠大，如果有500萬條記錄甚至1億條記錄呢？這個時候常規的數據結構的問題就凸顯出來了。
數組、鏈表、樹等數據結構會存儲元素的內容，一旦數據量過大，消耗的內存也會呈現線性增長，最終達到瓶頸。
有的同學可能會問，哈希表不是效率很高嗎？查詢效率可以達到O(1)。但是哈希表需要消耗的內存依然很高。
使用哈希表存儲一億個垃圾 email 地址的消耗？哈希表的做法：
首先，哈希函數將一個email地址映射成8字節信息指紋；考慮到哈希表存儲效率通常小於50%（哈希沖突）；因此消耗的內存：8 * 2 * 1億 字節 = 1.6G 內存，普通計算機是無法提供如此大的內存。
這個時候，布隆過濾器（Bloom Filter）就應運而生。在繼續介紹布隆過濾器的原理時，先講解下關於哈希函數的預備知識。
3、HashMap 的問題
講述布隆過濾器的原理之前，我們先思考一下，通常你判斷某個元素是否存在用的是什么？應該蠻多人回答 HashMap 吧，確實可以將值映射到 HashMap 的 Key，然后可以在 O(1) 的時間復雜度內返回結果，效率奇高。但是 HashMap 的實現也有缺點，例如存儲容量占比高，考慮到負載因子的存在，通常空間是不能被用滿的，而一旦你的值很多例如上億的時候，那 HashMap 占據的內存大小就變得很可觀了。
還比如說你的數據集存儲在遠程服務器上，本地服務接受輸入，而數據集非常大不可能一次性讀進內存構建 HashMap 的時候，也會存在問題。
二、哈希函數
哈希函數的概念是：將任意大小的數據轉換成特定大小的數據的函數，轉換后的數據稱為哈希值或哈希編碼。下面是一幅示意圖：
可以明顯的看到，原始數據經過哈希函數的映射后稱為了一個個的哈希編碼，數據得到壓縮。哈希函數是實現哈希表和布隆過濾器的基礎。
三、布隆過濾器介紹
- 巴頓.布隆於一九七零年提出
- 一個很長的二進制向量 （位數組）
- 一系列隨機函數 (哈希)
- 空間效率和查詢效率高
- 有一定的誤判率（哈希表是精確匹配）
我們需要知道的是：空間效率和查詢效率高，有一定誤判率即可（在可接受范圍內）。
本質上布隆過濾器是一種數據結構，比較巧妙的概率型數據結構（probabilistic data structure），特點是高效地插入和查詢，可以用來告訴你 “某樣東西一定不存在或者可能存在”。相比於傳統的 List、Set、Map 等數據結構，它更高效、占用空間更少，但是缺點是其返回的結果是概率性的，而不是確切的，並且刪除困難，不要鏡像刪除操作。
1、布隆過濾器數據結構
根據定義，布隆過濾器可以檢查值是 “可能在集合中” 還是 “絕對不在集合中”。“可能” 表示有一定的概率，也就是說可能存在一定為誤判率。那為什么會存在誤判呢？下面我們來分析一下具體的原因。
布隆過濾器是一個 bit 向量或者說 bit 數組，布隆過濾器（Bloom Filter）本質上是由長度為 m 的位向量或位列表（僅包含 0 或 1 位值的列表）組成，最初所有的值均設置為 0，如下圖所示。
為了將數據項添加到布隆過濾器中，我們會提供 K 個不同的哈希函數，並將結果位置上對應位的值置為 “1”。在前面所提到的哈希表中，我們使用的是單個哈希函數，因此只能輸出單個索引值。而對於布隆過濾器來說，我們將使用多個哈希函數，這將會產生多個索引值。
如上圖所示，當輸入 “semlinker” 時，預設的 3 個哈希函數將輸出 2、4、6，我們把相應位置 1。假設另一個輸入 ”kakuqo“，哈希函數輸出 3、4 和 7。
你可能已經注意到，索引位 4 已經被先前的 “semlinker” 標記了。此時，我們已經使用 “semlinker” 和 ”kakuqo“ 兩個輸入值，填充了位向量。當前位向量的標記狀態為：
當對值進行搜索時，與哈希表類似，我們將使用 3 個哈希函數對 ”搜索的值“ 進行哈希運算，並查看其生成的索引值。假設，當我們搜索 ”fullstack“ 時，3 個哈希函數輸出的 3 個索引值分別是 2、3 和 7。
從上圖可以看出，相應的索引位都被置為 1，這意味着我們可以說 ”fullstack“ 可能已經插入到集合中。事實上這是誤報的情形，產生的原因是由於哈希碰撞導致的巧合而將不同的元素存儲在相同的比特位上。幸運的是，布隆過濾器有一個可預測的誤判率（FPP）：
- n 是已經添加元素的數量；
- k 哈希的次數；
- m 布隆過濾器的長度（如比特數組的大小）；
極端情況下，當布隆過濾器沒有空閑空間時（滿），每一次查詢都會返回 true 。這也就意味着 m 的選擇取決於期望預計添加元素的數量 n ，並且 m 需要遠遠大於 n 。
實際情況中，布隆過濾器的長度 m 可以根據給定的誤判率（FFP）的和期望添加的元素個數 n 的通過如下公式計算：
了解完上述的內容之后，我們可以得出一個結論，當我們搜索一個值的時候，若該值經過 K 個哈希函數運算后的任何一個索引位為 ”0“，那么該值肯定不在集合中。但如果所有哈希索引值均為 ”1“，則只能說該搜索的值可能存在集合中。
這是為什么呢？答案跟簡單，因為隨着增加的值越來越多，被置為 1 的 bit 位也會越來越多，這樣某個值 “taobao” 即使沒有被存儲過，但是萬一哈希函數返回的三個 bit 位都被其他值置位了 1 ，那么程序還是會判斷 “taobao” 這個值存在。
2、布隆過濾器原理
布隆過濾器（Bloom Filter）的核心實現是一個超大的位數組和幾個哈希函數。假設位數組的長度為m，哈希函數的個數為 k
以上圖為例，具體的操作流程：假設集合里面有3個元素{x, y, z}，哈希函數的個數為3。
（1）首先，將位數組進行初始化，將里面每個位都設置位0。
（2）對於集合里面的每一個元素，將元素依次通過3個哈希函數進行映射，每次映射都會產生一個哈希值，這個值對應位數組上面的一個點，然后將位數組對應的位置標記為1。
（3）查詢W元素是否存在集合中的時候，同樣的方法將W通過哈希映射到位數組上的3個點。如果3個點的其中有一個點不為1，則可以判斷該元素一定不存在集合中。反之，如果3個點都為1，則該元素可能存在集合中。注意：此處不能判斷該元素是否一定存在集合中，可能存在一定的誤判率。
可以從圖中可以看到：假設某個元素通過映射對應下標為4，5，6這3個點。雖然這3個點都為1，但是很明顯這3個點是不同元素經過哈希得到的位置，因此這種情況說明元素雖然不在集合中，也可能對應的都是1，這是誤判率存在的原因。
3、布隆過濾器添加元素
（1）將要添加的元素給 k 個哈希函數
（2）得到對應於位數組上的 k 個位置
（3）將這 k 個位置設為1
4、布隆過濾器查詢元素
（1）將要查詢的元素給 k 個哈希函數
（2）得到對應於位數組上的 k 個位置
（3）如果k個位置有一個為0，則肯定不在集合中
（4）如果k個位置全部為1，則可能在集合中
5、優點
相比於其它的數據結構，布隆過濾器在空間和時間方面都有巨大的優勢。布隆過濾器存儲空間和插入/查詢時間都是常數。另外, Hash 函數相互之間沒有關系，方便由硬件並行實現。布隆過濾器不需要存儲元素本身，在某些對保密要求非常嚴格的場合有優勢。
布隆過濾器可以表示全集，其它任何數據結構都不能；
6、支持刪除么？
傳統的布隆過濾器並不支持刪除操作。但是名為 Counting Bloom filter 的變種可以用來測試元素計數個數是否絕對小於某個閾值，它支持元素刪除。可以參考文章 Counting Bloom Filter 的原理和實現
7、如何選擇哈希函數個數和布隆過濾器長度
很顯然，過小的布隆過濾器很快所有的 bit 位均為 1，那么查詢任何值都會返回“可能存在”，起不到過濾的目的了。布隆過濾器的長度會直接影響誤報率，布隆過濾器越長其誤報率越小。
另外，哈希函數的個數也需要權衡，個數越多則布隆過濾器 bit 位置位 1 的速度越快，且布隆過濾器的效率越低；但是如果太少的話，那我們的誤報率會變高。
四、布隆過濾器應用
在實際工作中，布隆過濾器常見的應用場景如下：
- 網頁爬蟲對 URL 去重，避免爬取相同的 URL 地址；
- 反垃圾郵件，從數十億個垃圾郵件列表中判斷某郵箱是否垃圾郵箱；
- Google Chrome 使用布隆過濾器識別惡意 URL；
- Medium 使用布隆過濾器避免推薦給用戶已經讀過的文章；
- Google BigTable，Apache HBbase 和 Apache Cassandra 使用布隆過濾器減少對不存在的行和列的查找。 除了上述的應用場景之外，布隆過濾器還有一個應用場景就是解決緩存穿透的問題。所謂的緩存穿透就是服務調用方每次都是查詢不在緩存中的數據，這樣每次服務調用都會到數據庫中進行查詢，如果這類請求比較多的話，就會導致數據庫壓力增大，這樣緩存就失去了意義。
利用布隆過濾器我們可以預先把數據查詢的主鍵，比如用戶 ID 或文章 ID 緩存到過濾器中。當根據 ID 進行數據查詢的時候，我們先判斷該 ID 是否存在，若存在的話，則進行下一步處理。若不存在的話，直接返回，這樣就不會觸發后續的數據庫查詢。需要注意的是緩存穿透不能完全解決，我們只能將其控制在一個可以容忍的范圍內。
五、布隆過濾器實戰
布隆過濾器有很多實現和優化，由 Google 開發著名的 Guava 庫就提供了布隆過濾器（Bloom Filter）的實現。在基於 Maven 的 Java 項目中要使用 Guava 提供的布隆過濾器，只需要引入以下坐標：
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>28.0-jre</version>
</dependency>
在導入 Guava 庫后，我們新建一個 BloomFilterDemo 類，在 main 方法中我們通過 BloomFilter.create 方法來創建一個布隆過濾器，接着我們初始化 1 百萬條數據到過濾器中，然后在原有的基礎上增加 10000 條數據並判斷這些數據是否存在布隆過濾器中：
import com.google.common.base.Charsets; import com.google.common.hash.BloomFilter; import com.google.common.hash.Funnels; public class BloomFilterDemo { public static void main(String[] args) { int total = 1000000; // 總數量
BloomFilter<CharSequence> bf = BloomFilter.create(Funnels.stringFunnel(Charsets.UTF_8), total); // 初始化 1000000 條數據到過濾器中
for (int i = 0; i < total; i++) { bf.put("" + i); } // 判斷值是否存在過濾器中
int count = 0; for (int i = 0; i < total + 10000; i++) { if (bf.mightContain("" + i)) { count++; } } System.out.println("已匹配數量 " + count); } }
當以上代碼運行后，控制台會輸出以下結果：已匹配數量 1000309
很明顯以上的輸出結果已經出現了誤報，因為相比預期的結果多了 309 個元素，誤判率為：309/(1000000 + 10000) * 100 ≈ 0.030594059405940593
如果要提高匹配精度的話，我們可以在創建布隆過濾器的時候設置誤判率 fpp：
BloomFilter<CharSequence> bf = BloomFilter.create( Funnels.stringFunnel(Charsets.UTF_8), total, 0.0002 );
在 BloomFilter 內部，誤判率 fpp 的默認值是 0.03：
// com/google/common/hash/BloomFilter.class
public static <T> BloomFilter<T> create(Funnel<? super T> funnel, long expectedInsertions) { return create(funnel, expectedInsertions, 0.03D); }
在重新設置誤判率為 0.0002 之后，我們重新運行程序，這時控制台會輸出以下結果：已匹配數量 1000003
通過觀察以上的結果，可知誤判率 fpp 的值越小，匹配的精度越高。當減少誤判率 fpp 的值，需要的存儲空間也越大，所以在實際使用過程中需要在誤判率和存儲空間之間做個權衡。