摘要:緩存穿透場景當通過一個去數據庫查詢出來的數據結果為緩存系統就不會緩存該數據每次該查詢都會經過數據庫層造成沒有必要的開銷解決方案將該緩存至緩存系統中為一個特殊值緩存失效場景由于初始化的時候某些緩存過期時間設置的都一樣一段時間以后緩存全部失效在
緩存穿透
場景:當通過一個key去數據庫查詢出來的數據結果為null,緩存系統就不會緩存該數據,每次該key查詢都會經過數據庫層,造成沒有必要的DB開銷
解決方案:將該key緩存至緩存系統中,value為一個特殊值(^^,&&...)
場景:由于初始化的時候某些緩存過期時間設置的都一樣,一段時間以后緩存全部失效,在這一瞬間的會增大DB的壓力
解決方案:在過期時間上加一個隨機值;分析用戶行為,盡量讓失效時間均勻分布
場景:key緩存過期失效而新緩存未到期間,該key的查詢所有請求都會去查詢數據,造成DB壓力上升,不必要的DB開銷
解決方案:
加鎖排隊重建,使請求可以串行化,而不用全部的請求都去查詢數據庫
假設key的過期時間是A,創建一個key_sign,它的過期時間比A小,查詢key的時候檢查key_sign是否已經過期,如果過期則加鎖后臺起一個線程異步去更新key的值,而實際的緩存沒有過期(如果實際緩存已經過期,需要加鎖排隊重建),但是會浪費雙份緩存
在原有的value中存一個過期值B,B比A小,取值的時候根據B判斷value是否過期,如果過期,解決方案同上
犧牲用戶體驗,當發現緩存中沒有對應的數據直接返回失敗,并且把需要的數據放入一個分布式隊列,后臺通過異步線程更新隊列中需要更新的緩存
緩存污染場景:一些非正常操作(導出excel,運營偶發性訪問)而導致內存中出現很多冷數據
解決方案:選取合適的緩存算法(LUR-N算法)
場景:緩存首次上線,如果網站的訪問量很大,所有的請求都經過數據庫(如果訪問量比較少,可以由用戶訪問自行緩存)
解決方案:緩存預熱,在系統上線之前,所有的緩存都預先加載完畢(增加一個刷新緩存程序,上線后手動刷新或發布時自動調用刷用)
緩存失效策略:添加key的時候要設置一個過期時間,采用惰性刪除和定時刪除相結合的策略刪除過期鍵
多級緩存:線程級->內存級->進程級->文件(靜態資源)->分布式(redis)->Db結果.
二級緩存:二級緩存更多的解決是,緩存穿透與程序的健壯性,當集中式緩存出現問題的時候,我們的應用能夠繼續運行;一些熱點數據做成內存緩存,這些數據是在上線之前是已知的(比如說秒殺,大促商品),通過配置定時任務定時刷新內存緩存,完成和分布式緩存的數據置換;更加自動化的方案,可以根據上游自動發現熱點數據,廣播消息替換現在集群中內存緩存的數據(但在整個集群中廣播,成本比較高,并且二級緩存的管理的成本也很大);
參考資料緩存穿透、并發和失效,來自一線架構師的解決方案
那些年我們一起追過的緩存寫法
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/61798.html
摘要:淺談網站性能之前端性能優化性能優化的目的無非是減少用戶流量消耗,提升用戶首屏體驗,提升用戶訪問速度,讓用戶專注內容本身。前端性能優化減少請求數量基本原理在瀏覽器與服務器進行通信時,主要是通過進行通信。 最近項目慢慢走上正軌,需求趨于平穩,這才想起需要對整站進行性能優化。經過一段時間的學習,結合現在項目的實際性能情況,發現確實有許多地方可以進行優化。于是就開始了我的前端性能優化之旅。以下...
摘要:淺談網站性能之前端性能優化性能優化的目的無非是減少用戶流量消耗,提升用戶首屏體驗,提升用戶訪問速度,讓用戶專注內容本身。前端性能優化減少請求數量基本原理在瀏覽器與服務器進行通信時,主要是通過進行通信。 最近項目慢慢走上正軌,需求趨于平穩,這才想起需要對整站進行性能優化。經過一段時間的學習,結合現在項目的實際性能情況,發現確實有許多地方可以進行優化。于是就開始了我的前端性能優化之旅。以下...
閱讀 922·2023-04-26 01:34
閱讀 3356·2023-04-25 20:58
閱讀 3258·2021-11-08 13:22
閱讀 2107·2019-08-30 14:17
閱讀 2521·2019-08-29 15:27
閱讀 2673·2019-08-29 12:45
閱讀 2996·2019-08-29 12:26
閱讀 2810·2019-08-28 17:51