redis快取雪崩和快取穿透

快取雪崩：由於原有的快取過期失效，新的快取還沒有快取進來，有乙隻請求快取請求不到，導致所有請求都跑去了資料庫，導致資料庫io、記憶體和cpu眼裡過大，甚至導致宕機，使得整個系統崩潰。

解決思路：

1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。

2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。

3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如：redis主備，但是雙快取涉及到更新事務的問題，update可能讀到髒資料，需要好好解決。

加鎖：加鎖排隊只是為了減輕資料庫的壓力，並沒有提高系統吞吐量。假設在高併發下，快取重建期間key是鎖著的，這是過來1000個請求999個都在阻塞的。同樣會導致使用者等待超時，這是個治標不治本的方法。

public class cachedemo
else
else
}return cachevalue;}}
}

標記失效快取：

快取標記：記錄快取資料是否過期，如果過期會觸發通知另外的執行緒在後台去更新實際key的快取。

快取資料：它的過期時間比快取標記的時間延長1倍，例：標記快取時間30分鐘，資料快取設定為60分鐘。這樣，當快取標記key過期後，實際快取還能把舊資料返回給呼叫端，直到另外的執行緒在後台更新完成後，才會返回新快取。

這樣做後，就可以一定程度上提高系統吞吐量。

public object getproductlistnew()
else
);return cachevalue;
}}

快取穿透：

快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空。這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。

解決的辦法就是：如果查詢資料庫也為空，直接設定乙個預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴。

快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫中查詢。

解決思路：

1，如果查詢資料庫也為空，直接設定乙個預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴。

2，根據快取資料key的規則。例如我們公司是做機頂盒的，快取資料以mac為key，mac是有規則，如果不符合規則就過濾掉，這樣可以過濾一部分查詢。在做快取規劃的時候，key有一定規則的話，可以採取這種辦法。這種辦法只能緩解一部分的壓力，過濾和系統無關的查詢，但是無法**。

3，採用布隆過濾器，將所有可能存在的資料雜湊到乙個足夠大的bitset中，不存在的資料將會被攔截掉，從而避免了對底層儲存系統的查詢壓力。關於布隆過濾器，詳情檢視：基於bitset的布隆過濾器(bloom filter)

大併發的快取穿透會導致快取雪崩。

public object getproductlistnew()
else
cachehelper.add(cachekey, cachevalue, cachetime);
return cachevalue;
}}

把空結果，也給快取起來，這樣下次同樣的請求就可以直接返回空了，即可以避免當查詢的值為空時引起的快取穿透。同時也可以單獨設定個快取區域儲存空值，對要查詢的key進行預先校驗，然後再放行給後面的正常快取處理邏輯。

快取預熱

快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣避免，使用者請求的時候，再去載入相關的資料。

解決思路：

1，直接寫個快取重新整理頁面，上線時手工操作下。

2，資料量不大，可以在web系統啟動的時候載入。

3，定時重新整理快取，

快取淘汰的策略有兩種：

(1) 定時去清理過期的快取。

(2)當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。

兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜，具體用哪種方案，大家可以根據自己的應用場景來權衡。1. 預估失效時間 2. 版本號（必須單調遞增，時間戳是最好的選擇）3. 提供手動清理快取的介面。