27.上的了天但落不了地的BloomFilter
1 BloomFilter是個(gè)好東西
它思路清奇，輾轉(zhuǎn)騰挪，號(hào)稱(chēng)可解決Redis緩存三大困境之首的穿透問(wèn)題，是后端面試必備的佳品，但你見(jiàn)過(guò)有文章介紹過(guò)BloomFilter怎么落地么？似乎沒(méi)有~
Redis緩存三大困境：穿透、擊穿、雪崩。null object可以解決正常的穿透問(wèn)題，然而面對(duì)黑客人惡意制作的穿透則無(wú)能為力，但BloomFilter可以。以用戶(hù)注冊(cè)登錄為例，BloomFilter通過(guò)預(yù)先收集所有有效uid，并創(chuàng)建一個(gè)多hash的bitmap向量，可以有效攔截惡意uid登錄的情況。
好了，從這里開(kāi)始，幾乎所有文章都會(huì)轉(zhuǎn)向介紹BloomFilter如何優(yōu)秀，或者其實(shí)現(xiàn)原理如何如何。但卻故意跳過(guò)了一個(gè)很關(guān)鍵的問(wèn)題：BloomFilter如何更新？
仍然以用戶(hù)注冊(cè)登錄為例。我們預(yù)先創(chuàng)建一個(gè)包含所有uid的bitmap向量沒(méi)有問(wèn)題，但是當(dāng)有新用戶(hù)注冊(cè)后，如何把新注冊(cè)用戶(hù)的uid加入到BloomFilter中呢？
2 看似可行的方案
1 Dual Write
中文翻譯為交叉寫(xiě)或雙寫(xiě)，即在新注冊(cè)用戶(hù)成功后，立馬把新注冊(cè)用戶(hù)的uid加入到BloomFilter中。
這個(gè)方案的優(yōu)點(diǎn)是實(shí)時(shí)性很好。但問(wèn)題是：萬(wàn)一新注冊(cè)用戶(hù)成功了，但寫(xiě)Redis失敗了怎么辦？比如有新用戶(hù)的注冊(cè)的時(shí)候，剛剛在MySQL注冊(cè)成功，但還未來(lái)得及寫(xiě)入到Redis時(shí)，由于網(wǎng)絡(luò)閃斷，寫(xiě)Redis超時(shí)了。此時(shí)MySQL就比Redis中多一個(gè)新注冊(cè)的用戶(hù)uid，該用戶(hù)在登錄系統(tǒng)就無(wú)法通過(guò)BloomFilter驗(yàn)證了。
只所以把Dual Write翻譯為『交叉寫(xiě)』，是暗含著在并發(fā)情形下，寫(xiě)入MySQL的順序與寫(xiě)入Redis的順序可能并不相同。這在很多情況下是無(wú)法接受的，比如用戶(hù)轉(zhuǎn)賬類(lèi)業(yè)務(wù)，也因此導(dǎo)致Dual Write不是一個(gè)常規(guī)方案。但在BloomFilter應(yīng)用場(chǎng)景中，恰好對(duì)不同用戶(hù)uid的寫(xiě)入順序不敏感。
2 Change Data Capture
數(shù)據(jù)變更捕獲，簡(jiǎn)稱(chēng)CDC。在我們的前述應(yīng)用場(chǎng)景中，簡(jiǎn)化的思路是新啟動(dòng)一個(gè)服務(wù)進(jìn)程，把自己模擬成MySQL的從庫(kù)，通過(guò)解析binlog，拿到新注冊(cè)用戶(hù)的uid，然后再將這個(gè)uid寫(xiě)入到BloomFilter中。
正式的CDC過(guò)程，通常會(huì)先把解析出來(lái)的binlog寫(xiě)入到kafka之類(lèi)的消息隊(duì)列中，通過(guò)消息隊(duì)列相關(guān)的可靠性方案保證新用戶(hù)的uid一定會(huì)寫(xiě)入到BloomFilter中，因此不會(huì)有丟消息的情形。
這個(gè)方案的優(yōu)點(diǎn)是可靠性很好。但問(wèn)題是：kafka消息消費(fèi)可能有延遲。假如我們新注冊(cè)了一個(gè)用戶(hù)，但1分鐘之后才消費(fèi)到該用戶(hù)的注冊(cè)消息，那么這1分鐘之內(nèi)該新用戶(hù)登錄系統(tǒng)也是通不過(guò)BloomFilter驗(yàn)證的。
3 落地方案
講了半天，應(yīng)該如何既要XX又要XX呢？
說(shuō)穿了一文不值：既然我們既想要Dual Write的實(shí)時(shí)性，又要CDC的可靠性，那么我們只要同時(shí)使用這兩個(gè)方案就好了~
4 別打我
但你可以來(lái)公眾號(hào)挑釁我，有本事你。。。。過(guò)來(lái)呀~