快取雪崩

快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都去查，導致CPU和記憶體負載過高，甚至宕機。

解決思路：

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

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

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

快取穿透

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

解決思路：下載

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

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

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

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

快取預熱

單機web系統情況下比較簡單。

解決思路：下載

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

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

3，搞個定時器定時重新整理快取，或者由使用者觸發都行。

分散式快取系統，如Memcached，比如快取系統比較大，由十幾臺甚至幾十臺機器組成，這樣預熱會複雜一些。

解決思路：

1，寫個程式去跑。

2，單個快取預熱框架。

快取預熱的目標就是在系統上線前，將資料載入到快取中。

快取

FIFO：First in First out，先進先出。原則：一個數據最先進入快取中，則應該最早淘汰掉。也就是說，當快取滿的時候，應當把最先進入快取的資料給淘汰掉。
LFU演算法：Least Frequently Used，最不經常使用演算法。
LRU演算法：Least Recently Used，近期最少使用演算法。請檢視：Memcached之你真正理解LRU嗎(4)

LRU和LFU的區別。LFU演算法是根據在一段時間裡資料項被使用的次數選擇出最少使用的資料項，即根據使用次數的差異來決定。而LRU是根據使用時間的差異來決定的