在日常開發過程中，為了提高查詢速度，我們通常會用到本地快取或分布式快取。特別是在高併發場景下使用分布式快取會遇到很多問題。主要可以歸為如下幾種：
接下來就看一看如何處理這些常見問題。
快取通常對資料庫資料快取。而分布式快取，還會存在主從結點。從結點會再同步主結點資料。因此在這種情況下訪問快取就可能導致快取中資料與資料庫資料不一致。或從結點資料與主幾點資料不一致。
對於一致性問題，通常會結合業務特點進行一定折衷，只要確保在業務可接收範圍內，實現最終一致即可。
對於寫快取更新，通常使用如下方式：
對於讀取快取，通常使用如下方式：
這時常用的方法如下：
互斥鎖：乙個執行緒去載入資料庫資料，再更新快取。其它執行緒等待重新整理完畢，重新從快取讀取資料。
本機快取可以使用鎖，而分布式快取可以根據具體使用的產品來決定。例如使用redis，可以考慮使用setnx。
以redis為例，一段偽**如下：
public string get
(string rediskey)
else
}return value;
}
後台執行緒重新整理：我們將過期時間記錄在快取值中，通過乙個後台執行緒去重新重新整理快取。這樣出現熱點key過期，不會出現全部請求訪問資料庫的情況。
接著對上述提到的幾種方式進行簡單的比較
方法優點
缺點互斥鎖
盡快保證一致性
後台執行緒重新整理
非同步重新整理，不會阻塞執行緒
1.不一致時間視窗會增大 2.需要在資料上維護額外的過期時間
快取穿透指查詢乙個不存在的資料，導致每次都不命中快取，最終都會去查詢資料庫，從而使快取失去意義。在流量大時，大量不存在的key導致db無法承受流量衝擊，可能會導致資料庫掛調。
常用解決方式如下： 方法
優點缺點
快取空資料
有效應對快取命中率不高的場景，即資料頻繁變化實時性強。
需要更多的空間，可能會有資料不一致問題
布隆過濾器
應用快取資料相對穩定的場景
開發量與空資料比較較多
快取層由於某些原因異常，無法提供服務，最終所有的請求都會達到資料庫層，所有資料庫的呼叫量會暴增，最終可能導致資料庫也掛掉。
這個問題就是要保證快取系統的可靠性。
快取常見問題就是資料不一致，以及快取失效或故障最終造成對後端資料庫造成衝擊使系統不可用。因此要明確原因，通過高質量**保證系統可靠。
高併發下快取失效問題
快取穿透 指查詢乙個一定不存在的資料，由於快取是不命中，將去查詢資料庫，但是資料庫也無此記錄，我們沒有將這次查詢的null寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義 風險 利用不存在的資料進行攻擊，資料庫瞬時壓力增大，最終導致崩潰 解決 null結果快取，並加入短...
高併發下快取失效問題
1.快取穿透 查詢乙個一定不存在的資料，由於快取一定不命中，將查詢資料庫，並且沒有將null寫入快取，這將導致這個不存在的資料每次請求都到儲存層查詢。風險 利用不存在的資料進行攻擊，資料庫瞬時壓力增大，最終導致崩潰。解決方案 null結果快取，並加入短暫過期時間。2.快取雪崩 指設定快取時key採用...
高併發快取常見問題及解決方案
快取穿透是指查詢乙個一定不存在的資料，由於快取是不命中時被動寫的，並且出於容錯考慮，如果從儲存層查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到儲存層去查詢，失去了快取的意義。在流量大時，可能db就掛掉了，要是有人利用不存在的key頻繁攻擊我們的應用，這就是漏洞。有很多種方法可以有效地...