大家都知道,在計算機中,IO一直是一個瓶頸,很多框架以及技術甚至硬件都是為了降低IO操作而生,今天聊一聊過濾器,先說一個場景:
我們業務后端涉及數據庫,當請求消息查詢某些信息時,可能先檢查緩存中是否有相關信息,有的話返回,如果沒有的話可能就要去數據庫里面查詢,這時候有一個問題,如果很多請求是在請求數據庫根本不存在的數據,那么數據庫就要頻繁響應這種不必要的IO查詢,如果再多一些,數據庫大多數IO都在響應這種毫無意義的請求操作,那么如何將這些請求阻擋在外呢?過濾器由此誕生:
- 布隆過濾器 -
布隆過濾器(Bloom Filter)大概的思路就是,當你請求的信息來的時候,先檢查一下你查詢的數據我這有沒有,有的話將請求壓給數據庫,沒有的話直接返回,是如何做到的呢?
如圖,一個bitmap用於記錄,bitmap原始數值全都是0,當一個數據存進來的時候,用三個Hash函數分別計算三次Hash值,並且將bitmap對應的位置設置為1,上圖中,bitmap 的1,3,6位置被標記為1,這時候如果一個數據請求過來,依然用之前的三個Hash函數計算Hash值,如果是同一個數據的話,勢必依舊是映射到1,3,6位,那么就可以判斷這個數據之前存儲過,如果新的數據映射的三個位置,有一個匹配不上,假如映射到1,3,7位,由於7位是0,也就是這個數據之前並沒有加入進數據庫,所以直接返回。
布隆過濾器的問題
上面這種方式,應該你已經發現了,布隆過濾器存在一些問題:
第一方面,布隆過濾器可能誤判:
假如有這么一個情景,放入數據包1時,將bitmap的1,3,6位設置為了1,放入數據包2時將bitmap的3,6,7位設置為了1,此時一個並沒有存過的數據包請求3,做三次哈希之后,對應的bitmap位點分別是1,6,7,這個數據之前並沒有存進去過,但是由於數據包1和2存入時將對應的點設置為了1,所以請求3也會壓倒數據庫上,這種情況,會隨着存入的數據增加而增加。
第二方面,布隆過濾器沒法刪除數據,刪除數據存在以下兩種困境:
一是,由於有誤判的可能,並不確定數據是否存在數據庫里,例如數據包3。
二是,當你刪除某一個數據包對應位圖上的標志后,可能影響其他的數據包,例如上面例子中,如果刪除數據包1,也就意味着會將bitmap1,3,6位設置為0,此時數據包2來請求時,會顯示不存在,因為3,6兩位已經被設置為0。
- 布隆過濾器增強版 -
為了解決上面布隆過濾器的問題,出現了一個增強版的布隆過濾器(Counting Bloom Filter),這個過濾器的思路是將布隆過濾器的bitmap更換成數組,當數組某位置被映射一次時就+1,當刪除時就-1,這樣就避免了普通布隆過濾器刪除數據后需要重新計算其余數據包Hash的問題,但是依舊沒法避免誤判。
- 布谷鳥過濾器 -
為了解決布隆過濾器不能刪除元素的問題, 論文《Cuckoo Filter：Better Than Bloom》作者提出了布谷鳥過濾器。相比布谷鳥過濾器，布隆過濾器有以下不足：查詢性能弱、空間利用效率低、不支持反向操作（刪除）以及不支持計數。
查詢性能弱是因為布隆過濾器需要使用多個 hash 函數探測位圖中多個不同的位點，這些位點在內存上跨度很大，會導致 CPU 緩存行命中率低。
空間效率低是因為在相同的誤判率下，布谷鳥過濾器的空間利用率要明顯高於布隆，空間上大概能節省 40% 多。不過布隆過濾器並沒有要求位圖的長度必須是 2 的指數，而布谷鳥過濾器必須有這個要求。從這一點出發，似乎布隆過濾器的空間伸縮性更強一些。
不支持反向刪除操作這個問題着實是擊中了布隆過濾器的軟肋。在一個動態的系統里面元素總是不斷的來也是不斷的走。布隆過濾器就好比是印跡，來過來就會有痕跡，就算走了也無法清理干凈。比如你的系統里本來只留下 1kw 個元素，但是整體上來過了上億的流水元素，布隆過濾器很無奈，它會將這些流失的元素的印跡也會永遠存放在那里。隨着時間的流失，這個過濾器會越來越擁擠，直到有一天你發現它的誤判率太高了，不得不進行重建。
布谷鳥過濾器在論文里聲稱自己解決了這個問題，它可以有效支持反向刪除操作。而且將它作為一個重要的賣點，誘惑你們放棄布隆過濾器改用布谷鳥過濾器。
為啥要取名布谷鳥呢?
有個成語，「鳩占鵲巢」,布谷鳥也是,布谷鳥從來不自己築巢。它將自己的蛋產在別人的巢里，讓別人來幫忙孵化。待小布谷鳥破殼而出之后，因為布谷鳥的體型相對較大，它又將養母的其它孩子（還是蛋）從巢里擠走 —— 從高空摔下夭折了。
- 布谷鳥哈希 -
最簡單的布谷鳥哈希結構是一維數組結構，會有兩個 hash 算法將新來的元素映射到數組的兩個位置。如果兩個位置中有一個位置為空，那么就可以將元素直接放進去。但是如果這兩個位置都滿了，它就不得不「鳩占鵲巢」，隨機踢走一個，然后自己霸占了這個位置。
p1 = hash1(x) % l
p2 = hash2(x) % l
復制代碼
不同於布谷鳥的是，布谷鳥哈希算法會幫這些受害者（被擠走的蛋）尋找其它的窩。因為每一個元素都可以放在兩個位置，只要任意一個有空位置，就可以塞進去。所以這個傷心的被擠走的蛋會看看自己的另一個位置有沒有空，如果空了，自己挪過去也就皆大歡喜了。但是如果這個位置也被別人占了呢？好，那么它會再來一次「鳩占鵲巢」，將受害者的角色轉嫁給別人。然后這個新的受害者還會重復這個過程直到所有的蛋都找到了自己的巢為止。
- 布谷鳥哈希的問題 -
但是會遇到一個問題，那就是如果數組太擁擠了，連續踢來踢去幾百次還沒有停下來，這時候會嚴重影響插入效率。這時候布谷鳥哈希會設置一個閾值，當連續占巢行為超出了某個閾值，就認為這個數組已經幾乎滿了。這時候就需要對它進行擴容，重新放置所有元素。
還會有另一個問題，那就是可能會存在擠兌循環。比如兩個不同的元素，hash 之后的兩個位置正好相同，這時候它們一人一個位置沒有問題。但是這時候來了第三個元素，它 hash 之后的位置也和它們一樣，很明顯，這時候會出現擠兌的循環。不過讓三個不同的元素經過兩次 hash 后位置還一樣，這樣的概率並不是很高，除非你的 hash 算法太挫了。
布谷鳥哈希算法對待這種擠兌循環的態度就是認為數組太擁擠了，需要擴容（實際上並不是這樣）。
優化
上面的布谷鳥哈希算法的平均空間利用率並不高，大概只有 50%。到了這個百分比，就會很快出現連續擠兌次數超出閾值。這樣的哈希算法價值並不明顯，所以需要對它進行改良。
改良的方案之一是增加 hash 函數，讓每個元素不止有兩個巢，而是三個巢、四個巢。這樣可以大大降低碰撞的概率，將空間利用率提高到 95%左右。
另一個改良方案是在數組的每個位置上掛上多個座位，這樣即使兩個元素被 hash 在了同一個位置，也不必立即「鳩占鵲巢」，因為這里有多個座位，你可以隨意坐一個。除非這多個座位都被占了，才需要進行擠兌。很明顯這也會顯著降低擠兌次數。這種方案的空間利用率只有 85%左右，但是查詢效率會很高，同一個位置上的多個座位在內存空間上是連續的，可以有效利用 CPU 高速緩存。
所以更加高效的方案是將上面的兩個改良方案融合起來，比如使用 4 個 hash 函數，每個位置上放 2 個座位。這樣既可以得到時間效率，又可以得到空間效率。這樣的組合甚至可以將空間利用率提到高 99%，這是非常了不起的空間效率。
布谷鳥過濾器
布谷鳥過濾器和布谷鳥哈希結構一樣，它也是一維數組，但是不同於布谷鳥哈希的是，布谷鳥哈希會存儲整個元素，而布谷鳥過濾器中只會存儲元素的指紋信息（幾個bit，類似於布隆過濾器）。這里過濾器犧牲了數據的精確性換取了空間效率。正是因為存儲的是元素的指紋信息，所以會存在誤判率，這點和布隆過濾器如出一轍。
首先布谷鳥過濾器還是只會選用兩個 hash 函數，但是每個位置可以放置多個座位。這兩個 hash 函數選擇的比較特殊，因為過濾器中只能存儲指紋信息。當這個位置上的指紋被擠兌之后，它需要計算出另一個對偶位置。而計算這個對偶位置是需要元素本身的，我們來回憶一下前面的哈希位置計算公式。
fp = fingerprint(x)
p1 = hash1(x) % l
p2 = hash2(x) % l
我們知道了 p1 和 x 的指紋，是沒辦法直接計算出 p2 的。
特殊的 hash 函數
布谷鳥過濾器巧妙的地方就在於設計了一個獨特的 hash 函數，使得可以根據 p1 和 元素指紋 直接計算出 p2，而不需要完整的 x 元素。
fp = fingerprint(x)
p1 = hash(x)
p2 = p1 ^ hash(fp) // 異或
從上面的公式中可以看出，當我們知道 fp 和 p1，就可以直接算出 p2。同樣如果我們知道 p2 和 fp，也可以直接算出 p1 —— 對偶性。
p1 = p2 ^ hash(fp)
所以我們根本不需要知道當前的位置是 p1 還是 p2，只需要將當前的位置和 hash(fp) 進行異或計算就可以得到對偶位置。而且只需要確保 hash(fp) != 0 就可以確保 p1 != p2，如此就不會出現自己踢自己導致死循環的問題。
也許你會問為什么這里的 hash 函數不需要對數組的長度取模呢？實際上是需要的，但是布谷鳥過濾器強制數組的長度必須是 2 的指數，所以對數組的長度取模等價於取 hash 值的最后 n 位。在進行異或運算時，忽略掉低 n 位 之外的其它位就行。將計算出來的位置 p 保留低 n 位就是最終的對偶位置。
在早期文章里面我曾經寫過布隆過濾器：
哎，這糟糕透頂的排版，一言難盡.......
其實寫文章和寫代碼一樣。
看到一段辣眼睛的代碼，正想口吐芬芳：這是哪個煞筆寫的代碼？
結果定睛一看，代碼上寫的作者居然是自己。
甚至還不敢相信，還要打開看一下 git 的提交記錄。
發現確實是自己幾個月前親手敲出來，並且提交的代碼。
於是默默的改掉。
出現這種情況我也常常安慰自己：沒事，這是好事啊，說明我在進步。
好了，說正事。
當時的文章里面我說布隆過濾器的內部原理我說不清楚。
其實我只是懶得寫而已，這玩意又不復雜，有啥說不清楚的？
布隆過濾器
布隆過濾器，在合理的使用場景中具有四兩撥千斤的作用，由於使用場景是在大量數據的場景下，所以這東西類似於秒殺，雖然沒有真的落地用過，但是也要說的頭頭是道。
常見於面試環節：比如大集合中重復數據的判斷、緩存穿透問題等。
先分享一個布隆過濾器在騰訊短視頻產品中的真實案例：
https://toutiao.io/posts/mtrvsx/preview
那么布隆過濾器是怎么做到上面的這些需求的呢？
首先，布隆過濾器並不存儲原始數據，因為它的功能只是針對某個元素，告訴你該元素是否存在而已。並不需要知道布隆過濾器里面有那些元素。
當然，如果我們知道容器里面有哪些元素，就可以知道一個元素是否存在。
但是，這樣我們需要把出現過的元素都存儲下來，大數據量的情況下，這樣的存儲就非常的占用空間。
布隆過濾器是怎么做到不存儲元素，又知道一個元素是否存在呢？
說破了其實就很簡單：一個長長的數組加上幾個 Hash 算法。
在上面的示意圖中，一共有三個不同的 Hash 算法、一個長度為 10 的數組，數組里面存儲的是 bit 位，只放 0 和 1。初始為 0。
假設現在有一個元素 [why] ，要經過這個布隆過濾器。
首先 [why] 分別經過三個 Hash 算法，得出三個不同的數字。
Hash 算法可以保證得出的數字是在 0 到 9 之間，即不超過數組長度。
我們假設計算結果如下：
- Hash1(why)=1
- Hash2(why)=4
- Hash3(why)=8
對應到圖片中就是這樣的：
這時，如果 [why] 又來了，經過 Hash 算法得出的下標還是 1,4,8，發現數組對應的位置上都是 1。表明這個元素極有可能出現過。
注意，這里說的是極有可能。也就是說會存在一定的誤判率。
我們先再存入一個元素 [jay]。
- Hash1(jay)=0
- Hash2(jay)=5
- Hash3(jay)=8
此時，我們把兩個元素匯合一下，就有了下面這個圖片：
其中的下標為 8 的位置，比較特殊，兩個元素都指向了它。
這個圖片這樣看起來有點難受，我美化一下：
好了，現在這個數組變成了這樣：
你說，你只看這個玩意，你能知道這個過濾器里面曾經有過 why 和 jay 嗎？
別說你不知道了，就連過濾器本身都不知道。
現在，假設又來了一個元素 [Leslie]，經過三個 Hash 算法，計算結果如下：
- Hash1(Leslie)=0
- Hash2(Leslie)=4
- Hash3(Leslie)=5
通過上面的元素，可以知道此時 0,4,5 這三個位置上都是 1。
布隆過濾器就會覺得這個元素之前可能出現過。於是就會返回給調用者：[Leslie]曾經出現過。
但是實際情況呢？
其實我們心里門清，[Leslie] 不曾來過。
這就是誤報的情況。
這就是前面說的：布隆過濾器說存在的元素，不一定存在。
而一個元素經過某個 hash 計算后，如果對應位置上的值是 0，那么說明該元素一定不存在。
但是它有一個致命的缺點，就是不支持刪除。
為什么？
假設要刪除 [why]，那么就要把 1,4,8 這三個位置置為 0。
但是你想啊，[jay] 也指向了位置 8 呀。
如果刪除 [why] ，位置 8 變成了 0，那么是不是相當於把 [jay] 也移除了？
為什么不支持刪除就致命了呢？
你又想啊，本來布隆過濾器就是使用於大數據量的場景下，隨着時間的流逝，這個過濾器的數組中為 1 的位置越來越多，帶來的結果就是誤判率的提升。從而必須得進行重建。
所以，文章開始舉的騰訊的例子中有這樣一句話：
除了刪除這個問題之外，布隆過濾器還有一個問題：查詢性能不高。
因為真實場景中過濾器中的數組長度是非常長的，經過多個不同 Hash 函數后，得到的數組下標在內存中的跨度可能會非常的大。跨度大，就是不連續。不連續，就會導致 CPU 緩存行命中率低。
這玩意，這么說呢。就當八股文背起來吧。
踏雪留痕，雁過留聲，這就是布隆過濾器。
如果你想玩一下布隆過濾器，可以訪問一下這個網站：
https://www.jasondavies.com/bloomfilter/
左邊插入，右邊查詢：
如果要布隆過濾器支持刪除，那么怎么辦呢？
有一個叫做 Counting Bloom Filter。
它用一個 counter 數組，替換數組的比特位，這樣一比特的空間就被擴大成了一個計數器。
用多占用幾倍的存儲空間的代價，給 Bloom Filter 增加了刪除操作。
這也是一個解決方案。
但是還有更好的解決方案，那就是布谷鳥過濾器。
另外，關於布隆過濾器的誤判率，有一個數學推理公式。很復雜，很枯燥，就不講了，有興趣的可以去了解一下。
http://pages.cs.wisc.edu/~cao/papers/summary-cache/node8.html
布谷鳥 hash
布谷鳥過濾器，第一次出現是在 2014 年發布的一篇論文里面：《Cuckoo Filter: Practically Better Than Bloom》
https://www.cs.cmu.edu/~dga/papers/cuckoo-conext2014.pdf
但是在講布谷鳥過濾器之前，得簡單的鋪墊一下 Cuckoo hashing，也就是布谷鳥 hash 的知識。
因為這個詞是論文的關鍵詞，在文中出現了 52 次之多。
Cuckoo hashing，最早出現在這篇 2001 年的論文之中：
https://www.cs.tau.ac.il/~shanir/advanced-seminar-data-structures-2009/bib/pagh01cuckoo.pdf
主要看論文的這個地方：
它的工作原理，總結起來是這樣的：
它有兩個 hash 表，記為 T1，T2。
兩個 hash 函數，記為 h1，h2。
當一個不存在的元素插入的時候，會先根據 h1 計算出其在 T1 表的位置，如果該位置為空則可以放進去。
如果該位置不為空，則根據 h2 計算出其在 T2 表的位置，如果該位置為空則可以放進去。
如果該位置不為空，就把當前位置上的元素踢出去，然后把當前元素放進去就行了。
也可以隨機踢出兩個位置中的一個，總之會有一個元素被踢出去。
被踢出去的元素怎么辦呢？
沒事啊，它也有自己的另外一個位置。
論文中的偽代碼是這樣的：
看不懂沒關系，我們畫個示意圖：
上面的圖說的是這樣的一個事兒：
我想要插入元素 x，經過兩個 hash 函數計算后，它的兩個位置分別為 T1 表的 2 號位置和 T2 表的 1 號位置。
兩個位置都被占了，那就隨機把 T1 表 2 號位置上的 y 踢出去吧。
而 y 的另一個位置被 z 元素占領了。
於是 y 毫不留情把 z 也踢了出去。
z 發現自己的備用位置還空着（雖然這個備用位置也是元素 v 的備用位置），趕緊就位。
所以，當 x 插入之后，圖就變成了這樣：
上面這個圖其實來源就是論文里面（a）：
這種類似於套娃的解決方式看是可行，但是總是有出現循環踢出導致放不進 x 的問題。
比如上圖中的（b）。
當遇到這種情況時候，說明布谷鳥 hash 已經到了極限情況，應該進行擴容，或者 hash 函數的優化。
所以，你再次去看偽代碼的時候，你會明白里面的 MaxLoop 的含義是什么了。
這個 MaxLoop 的含義就是為了避免相互踢出的這個過程執行次數太多，設置的一個閾值。
其實我理解，布谷鳥 hash 是一種解決 hash 沖突的騷操作。
如果你想上手玩一下，可以訪問這個網站：
http://www.lkozma.net/cuckoo_hashing_visualization/
當踢來踢去了 16 （MaxLoop）次還沒插入完成后，它會告訴你，需要 rehash 並對數組擴容了：
布谷鳥 hash 就是這么一回事，一場踢來踢去的游戲。
接着，我們看布谷鳥過濾器。
布谷鳥過濾器
布谷鳥過濾器的論文《Cuckoo Filter: Practically Better Than Bloom》開篇第一頁，里面有這樣一段話。
直接和布隆過濾器正面剛：我布谷鳥過濾器，就是比你屌一點。
上來就指着別人的軟肋懟：
標准的布隆過濾器的一大限制是不能刪除已經存在的數據。如果使用它的變種，比如 Counting Bloom Filter，但是空間卻被撐大了 3 到 4 倍，巴拉巴拉巴拉......
而我就比較騷了：
這篇論文將要證明的是，與標准布隆過濾器相比，我支持刪除，在空間或性能上並不需要更高的開銷。
我，布谷鳥過濾器是一個實用的數據結構，提供了四大優勢：
- 1.支持動態的新增和刪除元素。
- 2.提供了比傳統布隆過濾器更高的查找性能，即使在空間接近滿的情況下（比如空間利用率達到 95% 的時候）。
- 3.比諸如商過濾器（quotient filter，另一種過濾器）之類的替代方案更容易實現。
- 4.如果要求錯誤率小於 3%，那么在許多實際應用中，它比布隆過濾器占用的空間更小。
布谷鳥過濾器的 API 無非就是插入、查詢和刪除嘛。
其中最重要的就是插入，看一下：
論文中的部分，你大概瞟一眼，看不明白沒關系，我這不是馬上給你分析一波嗎。
插入部分的偽代碼，可以看到一點布谷鳥 hash 的影子，因為就是基於這個東西來的。
那么最大的變化在什么地方呢？
無非就是 hash 函數的變化。
看的我目瞪狗呆，心想：
首先，我們回憶一下布谷鳥 hash，它存儲的是插入元素的原始值，比如 x。
x 會經過兩個 hash 函數，如果我們記數組的長度為 L，那么就是這樣的：
- p1 = hash1(x) % L
- p2 = hash2(x) % L
非常容易理解，是我認知范圍內的東西。
而布谷鳥過濾器計算位置是怎樣的呢？
- h1(x) = hash(x),
- h2(x) = h1(x) ⊕ hash(x’s fingerprint).
我們可以看到，計算 h2（位置2）時，對 x 的 fingerprint 進行了一個 hash 計算。
“指紋”的概念一會再說，我們先關注位置的計算。
這題就稍微有點超綱了，我慢慢說。
上面算法中的異或運算確保了一個重要的性質：位置 h2 可以通過位置 h1 和 h1 中存儲的“指紋”計算出來。
說人話就是：只要我們知道一個元素的位置（h1）和該位置里面存儲的“指紋”信息，那么我們就可以知道該“指紋”的備用位置（h2）。
因為使用的異或運算，所以這兩個位置具有對偶性。
由於具有對偶性，那么其實我們只要知道其中的任意一個位置，就能知道對應的另外一個位置。
只要保證 hash(x’s fingerprint) !=0，那么就可以確保 h2!=h1，也就可以確保不會出現自己踢自己的死循環問題。
另外，為什么要對“指紋”進行一個 hash 計算之后，在進行異或運算呢？
論文中給出了一個反證法：如果不進行 hash 計算，假設“指紋”的長度是 8bit，那么其對偶位置算出來，距離當前位置最遠也才 256。
為啥，論文里面寫了：
因為如果“指紋”的長度是 8bit，那么異或操作只會改變當前位置 h1(x) 的低 8 位，高位不會改變。
就算把低 8 位全部改了，算出來的位置也就是我剛剛說的：最遠 256 位。
所以，對“指紋”進行哈希處理可確保被踢出去的元素，可以重新定位到哈希表中完全不同的存儲桶中，從而減少哈希沖突並提高表利用率。
然后這個 hash 函數還有個問題你發現了沒？
它沒有對數組的長度進行取模，那么它怎么保證計算出來的下標一定是落在數組中的呢？
這個就得說到布谷鳥過濾器的另外一個限制了。
其強制數組的長度必須是 2 的指數倍。
2 的指數倍的二進制一定是這樣的：10000000...（n個0）。
這個限制帶來的好處就是，進行異或運算時，可以保證計算出來的下標一定是落在數組中的。
這個限制帶來的壞處就是：
- 布谷鳥過濾器：我支持刪除操作。
- 布隆過濾器：我不需要限制長度為 2 的指數倍。
- 布谷鳥過濾器：我查找性能比你高。
- 布隆過濾器：我不需要限制長度為 2 的指數倍。
- 布谷鳥過濾器：我空間利用率也高。
- 布隆過濾器：我不需要限制長度為 2 的指數倍。
- 布谷鳥過濾器：我煩死了，TMD！
接下來，說一下“指紋”。
這是論文中第一次出現“指紋”的地方。
“指紋”其實就是插入的元素進行一個 hash 計算，而 hash 計算的產物就是幾個 bit 位。
布谷鳥過濾器里面存儲的就是元素的“指紋”。
查詢數據的時候，就是看看對應的位置上有沒有對應的“指紋”信息：
刪除數據的時候，也只是抹掉該位置上的“指紋”而已：
由於是對元素進行 hash 計算，那么必然會出現 hash 碰撞的問題，也就是“指紋”相同的情況，也就是會出現誤判的情況。
沒有存儲原數據，所以犧牲了數據的准確性，但是只保存了幾個 bit，因此提升了空間效率。
說到空間利用率，你想想布谷鳥 hash 的空間利用率是多少？
在完美的情況下，也就是沒有發生哈希沖突之前，它的空間利用率最高只有 50%。
因為沒有發生沖突，說明至少有一半的位置是空着的。
除了只存儲“指紋”，布谷鳥過濾器還能怎么提高它的空間利用率的呢？
看看論文里面怎么說的：
前面的 (a)、(b) 很簡單，還是兩個 hash 函數，但是沒有用兩個數組來存數據，就是基於一維數組的布谷鳥 hash ，核心還是踢來踢去，不多說了。
重點在於 (c)，對數組進行了展開，從一維變成了二維。
每一個下標，可以放 4 個元素了。
你可以理解為之前一個下標是一個圓板凳，上面只能放一個屁股。
而現在你可以把一個下標看成一個四方桌，可以坐四個人，打麻將了。
這樣一個小小的轉變，空間利用率從 50% 直接到了 98%：
我就問你怕不怕？
上面截圖的論文中的第一點就是在陳訴這樣一個事實：
當 hash 函數固定為 2 個的時候，如果一個下標只能放一個元素，那么空間利用率是 50%。
但是如果一個下標可以放 2，4，8 個元素的時候，空間利用率就會飆升到 84%，95%，98%。
到這里，我們明白了布谷鳥過濾器對布谷鳥 hash 的優化點和對應的工作原理。
看起來一切都是這么的完美。
各項指標都比布隆過濾器好，主打的是支持刪除的操作。
但是真的這么好嗎？
當我看到論文第六節的這一段的時候，沉默了：
對重復數據進行限制：如果需要布谷鳥過濾器支持刪除，它必須知道一個數據插入過多少次。不能讓同一個數據插入 kb+1 次。其中 k 是 hash 函數的個數，b 是一個下標的位置能放幾個元素。
比如 2 個 hash 函數，一個二維數組，它的每個下標最多可以插入 4 個元素。那么對於同一個元素，最多支持插入 8 次。
例如下面這種情況：
why 已經插入了 8 次了，如果再次插入一個 why，則會出現循環踢出的問題，直到最大循環次數，然后返回一個 false。
怎么避免這個問題呢？
我們維護一個記錄表，記錄每個元素插入的次數就行了。
雖然邏輯簡單，但是架不住數據量大呀。你想想，這個表的存儲空間又怎么算呢？
想想就難受。
如果你要用布谷鳥過濾器的刪除操作，那么這份難受，你不得不承受。
最后，再看一下各個類型過濾器的對比圖吧：
還有，其中的數學推理過程，不說了，看的眼睛疼，而且看這玩意容易掉頭發。
荒腔走板
你知道為什么叫做“布谷鳥”嗎？
布谷鳥，又叫杜鵑。
《本草綱目》有這樣的記載：“鳲鳩不能為巢，居他巢生子”。這里描述的就是杜鵑的巢寄生行為。巢寄生指的是鳥類自己不築巢，把卵產在其他種類鳥類的巢中，由宿主代替孵化育雛的繁殖方式，包括種間巢寄生（寄生者和宿主為不同物種）和種內巢寄生（寄生者和宿主為同一物種）。現今一萬多種鳥類中，有一百多種具有巢寄生的行為，其中最典型的就是大杜鵑。
就是說它自己把蛋下到別的鳥巢中，讓別的鳥幫它孵小雞。哦不，孵小鳥。
小杜鵑孵出來了后，還會把同巢的其他親生鳥蛋推出鳥巢，好讓母鳥專注於喂養它。
我的天吶，這也太殘忍了吧。
但是這個“推出鳥巢”的動作，不正和上面描述的算法是一樣的嗎？
只是我們的算法還更加可愛一點，被推出去的鳥蛋，也就是被踢出去的元素，會放到另外一個位置上去。
我查閱資料的時候，當我知道布谷鳥就是杜鵑鳥的時候我都震驚了。
好多詩句里面都有杜鵑啊，比如我很喜歡的，唐代詩人李商隱的《錦瑟》：
錦瑟無端五十弦，一弦一柱思華年。
庄生曉夢迷蝴蝶，望帝春心托杜鵑。
滄海月明珠有淚，藍田日暖玉生煙。
此情可待成追憶，只是當時已惘然。
自古以來。對於這詩到底是在說“悼亡”還是“自傷”的爭論就沒停止過。
但是這重要嗎？
對我來說這不重要。
重要的是，在適當的時機，適當的氣氛下，回憶起過去的事情的時候能適當的來上一句：“此情可待成追憶，只是當時已惘然”。
而不是說：哎，現在想起來，很多事情沒有好好珍惜，真TM后悔。
哦，對了。
寫文章的時候我還發現了一件事情。
布隆過濾器是 1970 年，一個叫做 Burton Howard Bloom 的大佬提出來的東西。
我寫這些東西的時候，就想看看大佬到底長什么樣子。
但是神奇的事情發生了，我前前后后，花了幾天，牆內牆外翻了個底朝天，居然沒有找到大佬的任何一張照片。
我的尋找，止步於發現了這個網站：
https://www.quora.com/Where-can-one-find-a-photo-and-biographical-details-for-Burton-Howard-Bloom-inventor-of-the-Bloom-filter
這個問題應該是在 9 年前就被人問出來了，也就是 2012 年的時候：
確實是在網上沒有找到關於 Burton Howard Bloom 的照片。
真是一個神奇又低調的大佬。
有可能是一個傾國傾城的美男子吧。