目錄

• 布隆過(guò)濾器
• Redis 緩存
• 穿透
• 雪崩
• 擊穿
• 熱點(diǎn)KEY

布隆過(guò)濾器

布隆過(guò)濾器（判斷某個(gè)key一定不存在）

本質(zhì)上布隆過(guò)濾器是一種數(shù)據(jù)結(jié)構(gòu)，比較巧妙的概率型數(shù)據(jù)結(jié)構(gòu)

特點(diǎn)是高效地插入和查詢，可以用來(lái)告訴你 “某樣?xùn)|西一定不存在或者可能存在”

相比于傳統(tǒng)的 List、Set、Map 等數(shù)據(jù)結(jié)構(gòu)，它更高效、占用空間更少，但是缺點(diǎn)是其返回的結(jié)果是概率性的，而不是確切的

布隆過(guò)濾器的使用：

• 布隆過(guò)濾器在NoSQL數(shù)據(jù)庫(kù)領(lǐng)域中應(yīng)用的非常廣泛
• 當(dāng)用戶來(lái)查詢某一個(gè)row時(shí)，可以先通過(guò)內(nèi)存中的布隆過(guò)濾器過(guò)濾掉大量不存在的row請(qǐng)求，然后去再磁盤進(jìn)行查詢
• 布隆過(guò)濾器說(shuō)某個(gè)值不存在時(shí)，那肯定就是不存在，可以顯著降低數(shù)據(jù)庫(kù)IO請(qǐng)求數(shù)量

應(yīng)用場(chǎng)景

• 場(chǎng)景1（給用戶推薦新聞）

當(dāng)用戶看過(guò)的新聞，肯定會(huì)被過(guò)濾掉，對(duì)于沒(méi)有看多的新聞，可能會(huì)過(guò)濾極少的一部分（誤判）

這樣可以完全保證推送給用戶的新聞都是無(wú)重復(fù)的

• 場(chǎng)景2（爬蟲url去重）

在爬蟲系統(tǒng)中，我們需要對(duì)url去重，已經(jīng)爬取的頁(yè)面不再爬取

當(dāng)url高達(dá)幾千萬(wàn)時(shí)，如果一個(gè)集合去裝下這些URL地址非常浪費(fèi)空間

使用布隆過(guò)濾器可以大幅降低去重存儲(chǔ)消耗，只不過(guò)也會(huì)使爬蟲系統(tǒng)錯(cuò)過(guò)少量頁(yè)面

布隆過(guò)濾器原理

添加：值到布隆過(guò)濾器

向布隆過(guò)濾器添加key,會(huì)使用 f、g、h hash函數(shù)對(duì)key算出一個(gè)整數(shù)索引，然后對(duì)長(zhǎng)度取余

每個(gè)hash函數(shù)都會(huì)算出一個(gè)不同的位置，把算出的位置都設(shè)置成1就完成了布隆過(guò)濾器添加過(guò)程

查詢：布隆過(guò)濾器值

當(dāng)查詢某個(gè)key時(shí)，先用hash函數(shù)算出一個(gè)整數(shù)索引，然后對(duì)長(zhǎng)度取余

當(dāng)你有一個(gè)不為1時(shí)肯定不存在這個(gè)key，當(dāng)全部都為1時(shí)可能有這個(gè)key

這樣內(nèi)存中的布隆過(guò)濾器過(guò)濾掉大量不存在的row請(qǐng)求，然后去再磁盤進(jìn)行查詢，減少IO操作

刪除：不支持

目前我們知道布隆過(guò)濾器可以支持 add 和 isExist 操作

如何解決這個(gè)問(wèn)題，答案是計(jì)數(shù)刪除，但是計(jì)數(shù)刪除需要存儲(chǔ)一個(gè)數(shù)值，而不是原先的 bit 位，會(huì)增大占用的內(nèi)存大小

增加一個(gè)值就是將對(duì)應(yīng)索引槽上存儲(chǔ)的值加一，刪除則是減一，判斷是否存在則是看值是否大于0

Redis 緩存

客戶端請(qǐng)求在緩存層命中直接返回內(nèi)容，如果Miss就去存儲(chǔ)層讀取，存儲(chǔ)層讀取到數(shù)據(jù)再寫入緩存層，然后再返回客戶端。

優(yōu)點(diǎn)：

• 加速讀寫效率
• 降低后端負(fù)載
• 減少存儲(chǔ)層壓力

缺點(diǎn)：

• 數(shù)據(jù)不能保證一致性
• 代碼維護(hù)成本和運(yùn)維成本
  

主從復(fù)制

• 主節(jié)點(diǎn)數(shù)據(jù)更新后根據(jù)配置和策略，自動(dòng)同步到備節(jié)點(diǎn)的master/slaver的機(jī)制
• 主節(jié)點(diǎn)負(fù)責(zé)寫數(shù)據(jù)，從節(jié)點(diǎn)負(fù)責(zé)讀數(shù)據(jù)
• 主節(jié)點(diǎn)定期把數(shù)據(jù)同步到從節(jié)點(diǎn)保證數(shù)據(jù)的一致性

優(yōu)點(diǎn)：

• 讀寫分離
• 容災(zāi)恢復(fù)

缺點(diǎn)：

• 主從復(fù)制，若主節(jié)點(diǎn)出現(xiàn)問(wèn)題，則不能提供服務(wù)，需要人工修改配置將從變主
• 主從復(fù)制主節(jié)點(diǎn)的寫能力單一，能力有限
• 單機(jī)節(jié)點(diǎn)的存儲(chǔ)能力也有限

穿透

定義

緩存穿透是指查詢一個(gè)一定不存在的數(shù)據(jù)，由于緩存不命中，接著查詢數(shù)據(jù)庫(kù)也無(wú)法查詢出結(jié)果

雖然也不會(huì)寫入到緩存中，但是這將會(huì)導(dǎo)致每個(gè)查詢都會(huì)去請(qǐng)求數(shù)據(jù)庫(kù)，造成緩存穿透

在查詢一個(gè)不存在的數(shù)據(jù)時(shí)，在緩存層查不到數(shù)據(jù)則會(huì)去訪問(wèn)存儲(chǔ)層，且返回的空數(shù)據(jù)也不會(huì)寫入緩存層。這將導(dǎo)致不存在的數(shù)據(jù)每次查詢都必定會(huì)到存儲(chǔ)層查詢，緩存層失去了存在的意義

當(dāng)大量惡意查詢不存在數(shù)據(jù)時(shí)，可能因?yàn)轭l繁訪問(wèn)導(dǎo)致數(shù)據(jù)庫(kù)宕機(jī)

解決方法 ：布隆過(guò)濾

• 對(duì)所有可能查詢的參數(shù)以hash形式存儲(chǔ)，在控制層先進(jìn)行校驗(yàn)，不符合則丟棄，將所有可能存在的數(shù)據(jù)哈希到一個(gè)足夠發(fā)的 bigmap 中
• 一個(gè)一定不存在的數(shù)據(jù)會(huì)被該 bigmap 攔截掉，從而避免對(duì)底層存儲(chǔ)系統(tǒng)造成查詢壓力

• 【推薦】如果一個(gè)查詢返回的數(shù)據(jù)為空（無(wú)論數(shù)據(jù)為空，或是系統(tǒng)故障），將空結(jié)果進(jìn)行緩存，設(shè)置一個(gè)最長(zhǎng)不超過(guò)五分鐘的過(guò)期時(shí)間。這樣過(guò)期時(shí)間內(nèi)查詢的時(shí)候就會(huì)直接在緩存層獲取，并直接返回null
  

雪崩

定義

緩存雪崩是指，由于緩存層承載著大量請(qǐng)求，有效的保護(hù)了存儲(chǔ)層，但是如果緩存層由于某些原因整體不能提供服務(wù)

于是所有的請(qǐng)求都會(huì)達(dá)到存儲(chǔ)層，存儲(chǔ)層的調(diào)用量會(huì)暴增，造成存儲(chǔ)層也會(huì)掛掉的情況

解決方法

• 哨兵
• 主服務(wù)器宕機(jī)，從服務(wù)器會(huì)主動(dòng)切換成主服務(wù)器
• 事前：redis 高可用，主從+哨兵，redis cluster，避免全盤崩潰。
• 事中：本地 ehcache 緩存 + hystrix 限流&降級(jí)，避免 MySQL 被打死。
• 事后：redis 持久化，一旦重啟，自動(dòng)從磁盤上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。

擊穿

定義：

緩存擊穿，就是說(shuō)某個(gè) key 非常熱點(diǎn)，訪問(wèn)非常頻繁，處于集中式高并發(fā)訪問(wèn)的情況

當(dāng)這個(gè) key 在失效的瞬間，大量的請(qǐng)求就擊穿了緩存，直接請(qǐng)求數(shù)據(jù)庫(kù)，就像是在一道屏障上鑿開了一個(gè)洞

解決方法

• 解決方式也很簡(jiǎn)單，可以將熱點(diǎn)數(shù)據(jù)設(shè)置為永遠(yuǎn)不過(guò)期
• 或者基于 redis or zookeeper 實(shí)現(xiàn)互斥鎖，等待第一個(gè)請(qǐng)求構(gòu)建完緩存之后，再釋放鎖，進(jìn)而其它請(qǐng)求才能通過(guò)該 key 訪問(wèn)數(shù)據(jù)

熱點(diǎn)KEY

熱點(diǎn)問(wèn)題產(chǎn)生的原因大致有以下兩種：

• 用戶消費(fèi)的數(shù)據(jù)遠(yuǎn)大于生產(chǎn)的數(shù)據(jù)（熱賣商品、熱點(diǎn)新聞、熱點(diǎn)評(píng)論、明星直播）

在日常工作生活中一些突發(fā)的的事件，例如：
雙十一期間某些熱門商品的降價(jià)促銷，當(dāng)這其中的某一件商品被數(shù)萬(wàn)次點(diǎn)擊瀏覽或者購(gòu)買時(shí)，會(huì)形成一個(gè)較大的需求量，這種情況下就會(huì)造成熱點(diǎn)問(wèn)題。
同理，被大量刊發(fā)、瀏覽的熱點(diǎn)新聞、熱點(diǎn)評(píng)論、明星直播等，這些典型的讀多寫少的場(chǎng)景也會(huì)產(chǎn)生熱點(diǎn)問(wèn)題

• 請(qǐng)求分片集中，超過(guò)單 Server 的性能極限

在服務(wù)端讀數(shù)據(jù)進(jìn)行訪問(wèn)時(shí)，往往會(huì)對(duì)數(shù)據(jù)進(jìn)行分片切分
此過(guò)程中會(huì)在某一主機(jī) Server 上對(duì)相應(yīng)的 Key 進(jìn)行訪問(wèn)，當(dāng)訪問(wèn)超過(guò) Server 極限時(shí)，就會(huì)導(dǎo)致熱點(diǎn) Key 問(wèn)題的產(chǎn)生

熱點(diǎn)問(wèn)題的危害

? 流量集中，達(dá)到物理網(wǎng)卡上限。

? 請(qǐng)求過(guò)多，緩存分片服務(wù)被打垮。

? DB 擊穿，引起業(yè)務(wù)雪崩。

如何解決熱點(diǎn)key的問(wèn)題

利用二級(jí)緩存

比如利用 ehcache ，或者一個(gè) HashMap 都可以。在你發(fā)現(xiàn)熱key以后，把熱key加載到系統(tǒng)的JVM中。

針對(duì)這種熱key請(qǐng)求，會(huì)直接從jvm中取，而不會(huì)走到redis層。

假設(shè)此時(shí)有十萬(wàn)個(gè)針對(duì)同一個(gè)key的請(qǐng)求過(guò)來(lái),如果沒(méi)有本地緩存，這十萬(wàn)個(gè)請(qǐng)求就直接懟到同一臺(tái)redis上了。

現(xiàn)在假設(shè)，你的應(yīng)用層有50臺(tái)機(jī)器，OK，你也有jvm緩存了。這十萬(wàn)個(gè)請(qǐng)求平均分散開來(lái)，每個(gè)機(jī)器有2000個(gè)請(qǐng)求，會(huì)從JVM中取到value值，然后返回?cái)?shù)據(jù)。避免了十萬(wàn)個(gè)請(qǐng)求懟到同一臺(tái)redis上的情形。

(2)備份熱key

這個(gè)方案也很簡(jiǎn)單。不要讓key走到同一臺(tái)redis上不就行了。我們把這個(gè)key，在多個(gè)redis上都存一份不就好了。接下來(lái)，有熱key請(qǐng)求進(jìn)來(lái)的時(shí)候，我們就在有備份的redis上隨機(jī)選取一臺(tái)，進(jìn)行訪問(wèn)取值，返回?cái)?shù)據(jù)。

• 來(lái)自于參考博客
• 參考博客鏈接

總結(jié)

以上是生活随笔為你收集整理的布隆过滤器Redis缓存穿透雪崩击穿热点key的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。