Redis-緩存穿透/擊穿/雪崩

1. 簡介

如圖所示，一個正常的請求

1. 客戶端請求張鐵牛的博客。
2. 服務首先會請求redis，查看請求的內容是否存在。
3. redis將請求結果返回給服務，若是返回的結果有數據則執行7；若是沒有數據則會繼續往下執行。
4. 服務從數據庫中查詢請求的數據。
5. 數據庫將查詢的結果返回給服務。
6. 若是數據庫有返回數據，則將返回的結果添加到redis。
7. 將請求到的數據返回給客戶端。

2. 緩存穿透

2.1描述

經過接口訪問一個緩存和數據庫都不存在的數據。

由於服務出於容錯考慮，當請求從持久層查不到數據則不寫入緩存，這將致使請求這個不存在的數據每次都要到持久層去查詢，失去了緩存的意義。

此時，緩存起不到保護後端持久層的意義，就像被穿透了同樣。致使數據庫存在被打掛的風險。

2.2 解決方案

1. 接口請求參數的校驗。對請求的接口進行鑑權，數據合法性的校驗等；好比查詢的userId不能是負值或者包含非法字符等。
2. 當數據庫返回空值時，將空值緩存到redis，並設置合理的過時時間。
3. 布隆過濾器。使用布隆過濾器存儲全部可能訪問的 key，不存在的 key 直接被過濾，存在的 key 則再進一步查詢緩存和數據庫。

3. 緩存擊穿

3.1 描述

某個熱點 key，在緩存過時的一瞬間，同時有大量的請求打進來，因爲此時緩存過時了，因此請求最終都會走到數據庫，形成瞬時數據庫請求量大、壓力驟增，致使數據庫存在被打掛的風險。

3.2 解決方案

1. 加互斥鎖。當熱點key過時後，大量的請求涌入時，只有第一個請求能獲取鎖並阻塞，此時該請求查詢數據庫，並將查詢結果寫入redis後釋放鎖。後續的請求直接走緩存。
2. 設置緩存不過時或者後臺有線程一直給熱點數據續期。

4. 緩存雪崩

4.1 描述

大量的熱點數據過時時間相同，致使數據在同一時刻集體失效。形成瞬時數據庫請求量大、壓力驟增，引發雪崩，致使數據庫存在被打掛的風險。

4.1 解決方案

1. 將熱點數據的過時時間打散。給熱點數據設置過時時間時加個隨機值。

2. 加互斥鎖。當熱點key過時後，大量的請求涌入時，只有第一個請求能獲取鎖並阻塞，此時該請求查詢數據庫，並將查詢結果寫入redis後釋放鎖。後續的請求直接走緩存。

3. 設置緩存不過時或者後臺有線程一直給熱點數據續期。

5. 布隆過濾器

5.1 描述

布隆過濾器是防止緩存穿透的方案之一。布隆過濾器主要是解決大規模數據下不須要精確過濾的業務場景，如檢查垃圾郵件地址，爬蟲URL地址去重， 解決緩存穿透問題等。

布隆過濾器：在一個存在必定數量的集合中過濾一個對應的元素，判斷該元素是否必定不在集合中或者可能在集合中。它的優勢是空間效率和查詢時間都比通常的算法要好的多，缺點是有必定的誤識別率和刪除困難。

5.2 數據結構

布隆過濾器是基於bitmap和若干個hash算法實現的。以下圖所示：

1. 元素tie通過hash1，hash2，hash3運算出對應的三個值落到了數組下標爲4，6，8的位置上，並將其位置的默認值0，修改爲1。
2. 元素niu同理落到了數組下標爲1，3，4的位置上，並將其位置的默認值0，修改爲1。

此時bitmap中已經存儲了tie，niu數據元素。

當請求想經過布隆過濾器判斷tie元素在程序中是否存在時，經過hash運算結果到數組對應下標位置上發現值已經都被置爲1，此時返回true。

5.3 「必定不在集合中」

如圖所示：

​ 元素zhang經過布隆過濾器判斷時，下標0，2都爲0，則直接返回false。

也就是當判斷不在bitmap中的元素時，通過hash運算獲得的結果在bitmap中只要有一個爲0，則該數據必定不存在。

5.4 「可能在集合中」

如圖所示：

​ 元素shuaibi經過布隆過濾器判斷時，hash運算的結果落到了下標1,3,8上，此時對應下標位置的值都爲1，則直接返回true。

這下就尷尬了，由於實際程序中並無數據shuaibi，但布隆過濾器返回的結果顯示有這個元素。這就是布隆過濾器的缺點，存在誤判狀況。

5.5 」刪除困難「

爲何布隆過濾器刪除困難呢，如圖所示：

若是刪除了「tie」元素，4號位被置爲0，則會影響niu元素的判斷，由於4號位爲0，進行數據校驗時返回0，則會認爲程序中沒有niu元素。

那小夥伴會問，4號位不置爲0，行不行？

若是刪除了元素，hash碰撞的數組下標不置爲0，那麼若是繼續驗證該元素的話，布隆過濾器會繼續返回true，但實際上元素已經刪除了。

因此布隆過濾器數據刪除困難，若是要刪除的話，能夠參考Counting Bloom Filter。

5.6 爲何不使用HashMap呢？

若是用HashSet或Hashmap存儲的話，每個用戶ID都要存成int，佔4個字節即32bit。而一個用戶在bitmap中只須要1個bit，內存節省了32倍。

而且大數據量會產生大量的hash衝突，結果就是產生hash衝突的數據，仍然會進行遍歷挨個比對（即便轉成紅黑樹），這樣對內存空間和查詢效率的提高，仍然是有限的。

固然：數據量不大時，儘管使用。並且hashmap方便進行CRUD😂