淺談緩存(一)

緩存穿透

場景:當經過一個key去數據庫查詢出來的數據結果爲null,緩存系統就不會緩存該數據,每次該key查詢都會通過數據庫層,形成沒有必要的DB開銷
解決方案:將該key緩存至緩存系統中,value爲一個特殊值(^^,&&...)

緩存失效

場景:因爲初始化的時候某些緩存過時時間設置的都同樣,一段時間之後緩存所有失效,在這一瞬間的會增大DB的壓力
解決方案:在過時時間上加一個隨機值;分析用戶行爲,儘可能讓失效時間均勻分佈

緩存雪崩

場景:key緩存過時失效而新緩存未到期間,該key的查詢全部請求都會去查詢數據,形成DB壓力上升,沒必要要的DB開銷
解決方案:

1. 加鎖排隊重建,使請求能夠串行化,而不用所有的請求都去查詢數據庫

2. 假設key的過時時間是A,建立一個key_sign,它的過時時間比A小,查詢key的時候檢查key_sign是否已通過期,若是過時則加鎖後臺起一個線程異步去更新key的值,而實際的緩存沒有過時(若是實際緩存已通過期,須要加鎖排隊重建),可是會浪費雙份緩存

3. 在原有的value中存一個過時值B,B比A小,取值的時候根據B判斷value是否過時,若是過時,解決方案同上

4. 犧牲用戶體驗,當發現緩存中沒有對應的數據直接返回失敗,而且把須要的數據放入一個分佈式隊列,後臺經過異步線程更新隊列中須要更新的緩存

緩存污染

場景:一些非正常操做(導出excel,運營偶發性訪問)而致使內存中出現不少冷數據
解決方案:選取合適的緩存算法(LUR-N算法)

緩存首次上線

場景:緩存首次上線,若是網站的訪問量很大,全部的請求都通過數據庫(若是訪問量比較少,能夠由用戶訪問自行緩存)
解決方案:緩存預熱,在系統上線以前,全部的緩存都預先加載完畢(增長一個刷新緩存程序,上線後手動刷新或發佈時自動調用刷用)

後記

1. 緩存失效策略:添加key的時候要設置一個過時時間,採用惰性刪除和定時刪除相結合的策略刪除過時鍵

2. 多級緩存:線程級->內存級->進程級->文件(靜態資源)->分佈式(redis)->Db結果.

3. 二級緩存:二級緩存更多的解決是,緩存穿透與程序的健壯性,當集中式緩存出現問題的時候,咱們的應用可以繼續運行;一些熱點數據作成內存緩存,這些數據是在上線以前是已知的(好比說秒殺,大促商品),經過配置定時任務定時刷新內存緩存,完成和分佈式緩存的數據置換;更加自動化的方案,能夠根據上游自動發現熱點數據,廣播消息替換如今集羣中內存緩存的數據(但在整個集羣中廣播,成本比較高,而且二級緩存的管理的成本也很大);

參考資料

緩存穿透、併發和失效，來自一線架構師的解決方案
那些年咱們一塊兒追過的緩存寫法