快取雪崩，快取穿透解決方案

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

解決思路：

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

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

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

4，做二級快取，或者雙快取策略。a1為原始快取，a2為拷貝快取，a1失效時，可以訪問a2，a1快取失效時間設定為短期，a2設定為長期。

解決思路：

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

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

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

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

解決思路：

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

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

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

解決思路：

1，寫個程式去跑。

2，單個快取預熱框架。

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

fifo演算法：first in first out，先進先出。原則：乙個資料最先進入快取中，則應該最早淘汰掉。也就是說，當快取滿的時候，應當把最先進入快取的資料給淘汰掉。

lfu演算法：least frequently used，最不經常使用演算法。

lru演算法：least recently used，近期最少使用演算法。請檢視：memcached之你真正理解lru嗎(4)

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

快取雪崩，快取穿透解決方案

負載過高，甚至宕機。解決思路 1，採用加鎖計數，或者使用合理的佇列數量來避免快取失效時對資料庫造成太大的壓力。這種辦法雖然能緩解資料庫的壓力，但是同時又降低了系統的吞吐量。2，分析使用者行為，盡量讓失效時間點均勻分布。避免快取雪崩的出現。3，如果是因為某台快取伺服器宕機，可以考慮做主備，比如 red...

快取雪崩，快取穿透解決方案

解決辦法 對所有可能查詢的引數以hash形式儲存，在控制層先進行校驗，不符合則丟棄。2.快取失效 如果快取集中在一段時間內失效，db的壓力凸顯。這個沒有完美解決辦法，但可以分析使用者行為，盡量讓失效時間點均勻分布。快取雪崩可能是因為資料未載入到快取中，或者快取同一時間大面積的失效，從而導致所有請求都...

快取雪崩和快取穿透解決方案

快取雪崩和快取穿透 快取雪崩 簡單的說就是快取失效，原本該訪問快取的資料直接訪問資料庫，從而造成資料庫和記憶體壓力大，嚴重的可能導致資料庫宕機 伺服器崩潰。解決方案 1.使用分布式鎖或者對列控制讀資料庫寫快取的執行緒數，保證這有乙個個執行緒進行操作。缺 點降低了系統的吞吐量 2.redis中的key...