這是why的第86篇原創文章
在早期文章裡面我曾經寫過布隆過濾器：
哎，這糟糕透頂的排版，一言難盡.......
其實寫文章和寫程式碼一樣。
看到一段辣眼睛的程式碼，正想口吐芬芳：這是哪個煞筆寫的程式碼？
結果定睛一看，程式碼上寫的作者居然是自己。
甚至還不敢相信，還要開啟看一下 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 插入之後，圖就變成了這樣：
上面這個圖其實來源就是論文裡面：
這種類似於套娃的解決方式看是可行，但是總是有出現迴圈踢出導致放不進 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 計算，那麼必然會出現“指紋”相同的情況，也就是會出現誤判的情況。
沒有儲存原資料，所以犧牲了資料的準確性，但是隻儲存了幾個 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 的照片。
真是一個神奇又低調的大佬。
有可能是一個傾國傾城的美男子吧。
最後說一句（求關注）
才疏學淺，難免會有紕漏，如果你發現了錯誤的地方，可以在後臺提出來，我對其加以修改。
感謝您的閱讀，我堅持原創，十分歡迎並感謝您的關注。
我是 why，一個主要寫程式碼，經常寫文章，偶爾拍視訊的程式猿。
還有，歡迎關注我呀。
