Redis總結（五）快取雪崩和快取穿透等問題
前面講過一些redis 快取的使用和資料持久化。感興趣的朋友可以看看之前的文章，http://www.cnblogs.com/zhangweizhong/category/771056.html 。今天總結總結快取使用過程中遇到的一些常見的問題。比如快取雪崩，快取穿透，快取預熱等等。
快取雪崩
快取雪崩是由於原有快取失效(過期)，新快取未到期間。所有請求都去查詢資料庫，而對資料庫CPU和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。
1. 碰到這種情況，一般併發量不是特別多的時候，使用最多的解決方案是加鎖排隊。
public object GetProductListNew()
{
const int cacheTime = 30;
const string cacheKey = "product_list";
const string lockKey = cacheKey;
var cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null)
{
return cacheValue;
}
else
{
lock (lockKey)
{
cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null)
{
return cacheValue;
}
else
{
cacheValue = GetProductListFromDB(); //這裡一般是 sql查詢資料。
CacheHelper.Add(cacheKey, cacheValue, cacheTime);
}
}
return cacheValue;
}
}
2. 加鎖排隊只是為了減輕資料庫的壓力，並沒有提高系統吞吐量。假設在高併發下，快取重建期間key是鎖著的，這是過來1000個請求999個都在阻塞的。同樣會導致使用者等待超時，這是個治標不治本的方法。
還有一個解決辦法解決方案是：給每一個快取資料增加相應的快取標記，記錄快取的是否失效，如果快取標記失效，則更新資料快取。
public object GetProductListNew()
{
const int cacheTime = 30;
const string cacheKey = "product_list";
//快取標記。
const string cacheSign = cacheKey + "_sign";
var sign = CacheHelper.Get(cacheSign);
//獲取快取值
var cacheValue = CacheHelper.Get(cacheKey);
if (sign != null)
{
return cacheValue; //未過期，直接返回。
}
else
{
CacheHelper.Add(cacheSign, "1", cacheTime);
ThreadPool.QueueUserWorkItem((arg) =>
{
cacheValue = GetProductListFromDB(); //這裡一般是 sql查詢資料。
CacheHelper.Add(cacheKey, cacheValue, cacheTime*2); //日期設快取時間的2倍，用於髒讀。
});
return cacheValue;
}
}
快取標記：記錄快取資料是否過期，如果過期會觸發通知另外的執行緒在後臺去更新實際key的快取。
快取資料：它的過期時間比快取標記的時間延長1倍，例：標記快取時間30分鐘，資料快取設定為60分鐘。 這樣，當快取標記key過期後，實際快取還能把舊資料返回給呼叫端，直到另外的執行緒在後臺更新完成後，才會返回新快取。
這樣做後，就可以一定程度上提高系統吞吐量。
快取穿透
快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後返回空。這樣請求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。
解決的辦法就是：如果查詢資料庫也為空，直接設定一個預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫，這種辦法最簡單粗暴。
public object GetProductListNew()
{
const int cacheTime = 30;
const string cacheKey = "product_list";
var cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null)
return cacheValue;
cacheValue = CacheHelper.Get(cacheKey);
if (cacheValue != null)
{
return cacheValue;
}
else
{
cacheValue = GetProductListFromDB(); //資料庫查詢不到，為空。
if (cacheValue == null)
{
cacheValue = string.Empty; //如果發現為空，設定個預設值，也快取起來。
}
CacheHelper.Add(cacheKey, cacheValue, cacheTime);
return cacheValue;
}
}
把空結果，也給快取起來，這樣下次同樣的請求就可以直接返回空了，即可以避免當查詢的值為空時引起的快取穿透。同時也可以單獨設定個快取區域儲存空值，對要查詢的key進行預先校驗，然後再放行給後面的正常快取處理邏輯。
快取預熱
快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣避免，使用者請求的時候，再去載入相關的資料。
解決思路：
1，直接寫個快取重新整理頁面，上線時手工操作下。
2，資料量不大，可以在WEB系統啟動的時候載入。
3，定時重新整理快取，
快取更新
快取淘汰的策略有兩種：
(1) 定時去清理過期的快取。
(2)當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過來都要判斷快取失效，邏輯相對比較複雜，具體用哪種方案，大家可以根據自己的應用場景來權衡。1. 預估失效時間 2. 版本號（必須單調遞增，時間戳是最好的選擇）3. 提供手動清理快取的介面。
我前面有篇文章，是介紹快取系統的快取更新的。感興趣的朋友可以看看：http://www.cnblogs.com/zhangweizhong/p/5884761.html
總結
這些都是實際專案中，可能碰到的一些問題。實際上還有很多很多各種各樣的問題。快取層框架的封裝往往要複雜的多。應用場景不同，方法和解決方案也不同。具體要根據實際情況來取捨。