快取雪崩

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

解決思路：

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

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

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

快取穿透

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

解決思路：

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

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

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

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

快取預熱

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

解決思路：

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

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

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

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