【轉】Memcached之緩衝雪崩，緩衝穿透，緩衝預熱，緩衝演算法

標籤：上線   定時重新整理   並發   bsp   簡單   部分   分布式   first   log   

緩衝雪崩

緩衝雪崩可能是因為資料未載入到緩衝中，或者緩衝同一時間大面積的失效，從而導致所有請求都去查資料庫，導致資料庫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，比如緩衝系統比較大，由十幾台甚至幾十台機器組成，這樣預熱會複雜一些。

解決思路：

1，寫個程式去跑。

2，單個緩衝預熱架構。

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

 

緩衝演算法

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

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

【轉】Memcached之緩衝雪崩，緩衝穿透，緩衝預熱，緩衝演算法