今天又學到了很多，感覺雪崩和穿透很有意思理解起來也比較清晰，然后我搜索了一些資料，給自己做一個普及

我們通常使用 緩存 + 過期時間的策略來幫助我們加速接口的訪問速度，減少了后端負載，同時保證功能的更新

緩存穿透

緩存系統(tǒng)，按照KEY去查詢VALUE,當KEY對應的VALUE一定不存在的時候并對KEY并發(fā)請求量很大的時候，就會對后端造成很大的壓力。

（查詢一個必然不存在的數(shù)據(jù)。比如文章表，查詢一個不存在的id，每次都會訪問DB，如果有人惡意破壞，很可能直接對DB造成影響。）

由于緩存不命中，每次都要查詢持久層。從而失去緩存的意義。

解決方法：

1、緩存層緩存空值。

–緩存太多空值，占用更多空間。（優(yōu)化：給個空值過期時間）
–存儲層更新代碼了，緩存層還是空值。（優(yōu)化：后臺設置時主動刪除空值，并緩存把值進去）

2、將數(shù)據(jù)庫中所有的查詢條件，放到布隆過濾器中。當一個查詢請求來臨的時候，先經(jīng)過布隆過濾器進行檢查，如果請求存在這個條件中，那么繼續(xù)執(zhí)行，如果不在，直接丟棄。

備注：

比如數(shù)據(jù)庫中有10000個條件，那么布隆過濾器的容量size設置的要稍微比10000大一些，比如12000.

對于誤判率的設置，根據(jù)實際項目，以及硬件設施來具體決定。但是一定不能設置為0，并且誤判率設置的越小，哈希函數(shù)跟數(shù)組長度都會更多跟更長，那么對硬件，內(nèi)存中間的要求就會相應的高。

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size, 0.0001);

有了size跟誤判率，那么布隆過濾器就會產(chǎn)生相應的哈希函數(shù)跟數(shù)組。

綜上：我們可以利用布隆過濾器，將redis緩存擊穿控制在一個可容忍的范圍內(nèi)。

緩存雪崩（緩存失效）

如果緩存集中在一段時間內(nèi)失效，發(fā)生大量的緩存穿透，所有的查詢都落在數(shù)據(jù)庫上，造成了緩存雪崩。

緩存層宕掉后，流量會像奔逃的野牛一樣，打向后端存儲

解決方法：

• 在緩存失效后，通過加鎖或者隊列來控制讀數(shù)據(jù)庫寫緩存的線程數(shù)量。比如對某個key只允許一個線程查詢數(shù)據(jù)和寫緩存，其他線程等待。
• 可以通過緩存reload機制，預先去更新緩存，再即將發(fā)生大并發(fā)訪問前手動觸發(fā)加載緩存
• 不同的key，設置不同的過期時間，讓緩存失效的時間點盡量均勻
• 做二級緩存，或者雙緩存策略。A1為原始緩存，A2為拷貝緩存，A1失效時，可以訪問A2，A1緩存失效時間設置為短期，A2設置為長期。
  

熱點key

(1) 這個key是一個熱點key（例如一個重要的新聞，一個熱門的八卦新聞等等），所以這種key訪問量可能非常大。

(2) 緩存的構建是需要一定時間的。（可能是一個復雜計算，例如復雜的sql、多次IO、多個依賴(各種接口)等等）

于是就會出現(xiàn)一個致命問題：在緩存失效的瞬間，有大量線程來構建緩存（見下圖），造成后端負載加大，甚至可能會讓系統(tǒng)崩潰 。

解決方法：

1. 使用互斥鎖(mutex key):這種解決方案思路比較簡單，就是只讓一個線程構建緩存，其他線程等待構建緩存的線程執(zhí)行完，重新從緩存獲取數(shù)據(jù)就可以了

2. "提前"使用互斥鎖(mutex key)：在value內(nèi)部設置1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當從cache讀取到timeout1發(fā)現(xiàn)它已經(jīng)過期時候，馬上延長timeout1并重新設置到cache。然后再從數(shù)據(jù)庫加載數(shù)據(jù)并設置到cache中。

3. "永遠不過期"：

這里的“永遠不過期”包含兩層意思：

(1) 從redis上看，確實沒有設置過期時間，這就保證了，不會出現(xiàn)熱點key過期問題，也就是“物理”不過期。

(2) 從功能上看，如果不過期，那不就成靜態(tài)的了嗎？所以我們把過期時間存在key對應的value里，如果發(fā)現(xiàn)要過期了，通過一個后臺的異步線程進行緩存的構建，也就是“邏輯”過期

4. 資源保護：可以做資源的隔離保護主線程池，如果把這個應用到緩存的構建也未嘗不可。

四種方案對比：

作為一個并發(fā)量較大的互聯(lián)網(wǎng)應用，我們的目標有3個:

1. 加快用戶訪問速度，提高用戶體驗。

2. 降低后端負載，保證系統(tǒng)平穩(wěn)。

3. 保證數(shù)據(jù)“盡可能”及時更新(要不要完全一致，取決于業(yè)務，而不是技術。)

所以第二節(jié)中提到的四種方法，可以做如下比較，還是那就話：沒有最好，只有最合適。

總結

1. 熱點key + 過期時間 + 復雜的構建緩存過程 => mutex key問題

2. 構建緩存一個線程做就可以了。

3. 四種解決方案：沒有最佳只有最合適。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。