目錄

• 布隆過濾器
• Redis 緩存
• 穿透
• 雪崩
• 擊穿
• 熱點KEY

布隆過濾器

布隆過濾器（判斷某個key一定不存在）

本質上布隆過濾器是一種數據結構，比較巧妙的概率型數據結構

特點是高效地插入和查詢，可以用來告訴你 “某樣東西一定不存在或者可能存在”

相比于傳統的 List、Set、Map 等數據結構，它更高效、占用空間更少，但是缺點是其返回的結果是概率性的，而不是確切的

布隆過濾器的使用：

• 布隆過濾器在NoSQL數據庫領域中應用的非常廣泛
• 當用戶來查詢某一個row時，可以先通過內存中的布隆過濾器過濾掉大量不存在的row請求，然后去再磁盤進行查詢
• 布隆過濾器說某個值不存在時，那肯定就是不存在，可以顯著降低數據庫IO請求數量

應用場景

• 場景1（給用戶推薦新聞）

當用戶看過的新聞，肯定會被過濾掉，對于沒有看多的新聞，可能會過濾極少的一部分（誤判）

這樣可以完全保證推送給用戶的新聞都是無重復的

• 場景2（爬蟲url去重）

在爬蟲系統中，我們需要對url去重，已經爬取的頁面不再爬取

當url高達幾千萬時，如果一個集合去裝下這些URL地址非常浪費空間

使用布隆過濾器可以大幅降低去重存儲消耗，只不過也會使爬蟲系統錯過少量頁面

布隆過濾器原理

添加：值到布隆過濾器

向布隆過濾器添加key,會使用 f、g、h hash函數對key算出一個整數索引，然后對長度取余

每個hash函數都會算出一個不同的位置，把算出的位置都設置成1就完成了布隆過濾器添加過程

查詢：布隆過濾器值

當查詢某個key時，先用hash函數算出一個整數索引，然后對長度取余

當你有一個不為1時肯定不存在這個key，當全部都為1時可能有這個key

這樣內存中的布隆過濾器過濾掉大量不存在的row請求，然后去再磁盤進行查詢，減少IO操作

刪除：不支持

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

如何解決這個問題，答案是計數刪除，但是計數刪除需要存儲一個數值，而不是原先的 bit 位，會增大占用的內存大小

增加一個值就是將對應索引槽上存儲的值加一，刪除則是減一，判斷是否存在則是看值是否大于0

Redis 緩存

客戶端請求在緩存層命中直接返回內容，如果Miss就去存儲層讀取，存儲層讀取到數據再寫入緩存層，然后再返回客戶端。

優點：

• 加速讀寫效率
• 降低后端負載
• 減少存儲層壓力

缺點：

• 數據不能保證一致性
• 代碼維護成本和運維成本
  

主從復制

• 主節點數據更新后根據配置和策略，自動同步到備節點的master/slaver的機制
• 主節點負責寫數據，從節點負責讀數據
• 主節點定期把數據同步到從節點保證數據的一致性

優點：

• 讀寫分離
• 容災恢復

缺點：

• 主從復制，若主節點出現問題，則不能提供服務，需要人工修改配置將從變主
• 主從復制主節點的寫能力單一，能力有限
• 單機節點的存儲能力也有限

穿透

定義

緩存穿透是指查詢一個一定不存在的數據，由于緩存不命中，接著查詢數據庫也無法查詢出結果

雖然也不會寫入到緩存中，但是這將會導致每個查詢都會去請求數據庫，造成緩存穿透

在查詢一個不存在的數據時，在緩存層查不到數據則會去訪問存儲層，且返回的空數據也不會寫入緩存層。這將導致不存在的數據每次查詢都必定會到存儲層查詢，緩存層失去了存在的意義

當大量惡意查詢不存在數據時，可能因為頻繁訪問導致數據庫宕機

解決方法 ：布隆過濾

• 對所有可能查詢的參數以hash形式存儲，在控制層先進行校驗，不符合則丟棄，將所有可能存在的數據哈希到一個足夠發的 bigmap 中
• 一個一定不存在的數據會被該 bigmap 攔截掉，從而避免對底層存儲系統造成查詢壓力

• 【推薦】如果一個查詢返回的數據為空（無論數據為空，或是系統故障），將空結果進行緩存，設置一個最長不超過五分鐘的過期時間。這樣過期時間內查詢的時候就會直接在緩存層獲取，并直接返回null
  

雪崩

定義

緩存雪崩是指，由于緩存層承載著大量請求，有效的保護了存儲層，但是如果緩存層由于某些原因整體不能提供服務

于是所有的請求都會達到存儲層，存儲層的調用量會暴增，造成存儲層也會掛掉的情況

解決方法

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

擊穿

定義：

緩存擊穿，就是說某個 key 非常熱點，訪問非常頻繁，處于集中式高并發訪問的情況

當這個 key 在失效的瞬間，大量的請求就擊穿了緩存，直接請求數據庫，就像是在一道屏障上鑿開了一個洞

解決方法

• 解決方式也很簡單，可以將熱點數據設置為永遠不過期
• 或者基于 redis or zookeeper 實現互斥鎖，等待第一個請求構建完緩存之后，再釋放鎖，進而其它請求才能通過該 key 訪問數據

熱點KEY

熱點問題產生的原因大致有以下兩種：

• 用戶消費的數據遠大于生產的數據（熱賣商品、熱點新聞、熱點評論、明星直播）

在日常工作生活中一些突發的的事件，例如：
雙十一期間某些熱門商品的降價促銷，當這其中的某一件商品被數萬次點擊瀏覽或者購買時，會形成一個較大的需求量，這種情況下就會造成熱點問題。
同理，被大量刊發、瀏覽的熱點新聞、熱點評論、明星直播等，這些典型的讀多寫少的場景也會產生熱點問題

• 請求分片集中，超過單 Server 的性能極限

在服務端讀數據進行訪問時，往往會對數據進行分片切分
此過程中會在某一主機 Server 上對相應的 Key 進行訪問，當訪問超過 Server 極限時，就會導致熱點 Key 問題的產生

熱點問題的危害

? 流量集中，達到物理網卡上限。

? 請求過多，緩存分片服務被打垮。

? DB 擊穿，引起業務雪崩。

如何解決熱點key的問題

利用二級緩存

比如利用 ehcache ，或者一個 HashMap 都可以。在你發現熱key以后，把熱key加載到系統的JVM中。

針對這種熱key請求，會直接從jvm中取，而不會走到redis層。

假設此時有十萬個針對同一個key的請求過來,如果沒有本地緩存，這十萬個請求就直接懟到同一臺redis上了。

現在假設，你的應用層有50臺機器，OK，你也有jvm緩存了。這十萬個請求平均分散開來，每個機器有2000個請求，會從JVM中取到value值，然后返回數據。避免了十萬個請求懟到同一臺redis上的情形。

(2)備份熱key

這個方案也很簡單。不要讓key走到同一臺redis上不就行了。我們把這個key，在多個redis上都存一份不就好了。接下來，有熱key請求進來的時候，我們就在有備份的redis上隨機選取一臺，進行訪問取值，返回數據。

• 來自于參考博客
• 參考博客鏈接

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。