Guava Cache是一款非常優秀的本地緩存框架。
這篇文章,我們聊聊如何使用 Guava Cache 異步刷新技巧帶飛系統性能 。
圖片
Guava Cache 的數據結構跟 JDK1.7 的 ConcurrentHashMap 類似,提供了基于時間、容量、引用三種回收策略,以及自動加載、訪問統計等功能。
圖片
首先,我們溫習下 Gauva Cache 的經典配置 。
圖片
例子中,緩存最大容量設置為 100 (基于容量進行回收),配置了失效策略和刷新策略。
配置 expireAfterWrite 后,緩存項在被創建或最后一次更新后的指定時間內會過期。
配置 refreshAfterWrite 設置刷新時間,當緩存項過期的同時可以重新加載新值 。
這個例子里,有的同學可能會有疑問:為什么需要配置刷新策略,只配置失效策略不就可以嗎?
當然是可以的,但在高并發場景下,配置刷新策略會有奇效,接下來,我們會寫一個測試用例,方便大家理解 Gauva Cache 的線程模型。
我們模擬在多線程場景下,「緩存過期執行 load 方法」和「刷新執行 reload 方法」兩者的運行情況。
圖片
執行結果見下圖:
圖片
執行結果表明:Guava Cache 并沒有后臺任務線程異步的執行 load 或者 reload 方法。
失效策略:expireAfterWrite 允許一個線程執行 load 方法,其他線程阻塞等待 。當大量線程用相同的 key 獲取緩存值時,只會有一個線程進入 load 方法,而其他線程則等待,直到緩存值被生成。這樣也就避免了緩存擊穿的危險。高并發場景下 ,這樣還是會阻塞大量線程。
刷新策略:refreshAfterWrite 允許一個線程執行 load 方法,其他線程返回舊的值。單個 key 并發下,使用 refreshAfterWrite ,雖然不會阻塞了,但是如果恰巧同時多個 key 同時過期,還是會給數據庫造成壓力。
為了提升系統性能,我們可以從如下兩個方面來優化 :
下圖展示優化方案的時間軸 :
圖片
圖片
圖片
不管使用哪種方案, 都需要定義單獨的線程池來執行刷新任務 。
2018 年,筆者服務的一家電商公司需要進行 app 首頁接口的性能優化。筆者花了大概兩天的時間完成了整個方案,采取的是兩級緩存模式,同時采用了 Guava 的異步刷新機制。
整體架構如下圖所示:
圖片
緩存讀取流程如下 :
優化后,性能表現很好,平均耗時在 5ms 左右,同時大幅度的減少應用 GC 的頻率。
該方案依然有瑕疵,一天晚上我們發現 app 端首頁顯示的數據時而相同,時而不同。
也就是說:雖然 LoadingCache 線程一直在調用接口更新緩存信息,但是各個服務器本地緩存中的數據并非完成一致。
這說明了兩個很重要的點:
最終,我們的解決方案是:
Guava Cache 非常強大,它并沒有后臺任務線程異步的執行 load 或者 reload 方法,而是通過請求線程來執行相關操作。
為了提升系統性能,我們可以從如下兩個方面來處理 :
筆者曾經優化過某電商網站的首頁接口,使用的方案是:Guava 的異步刷新機制 + 多級緩存 ,取得了非常好的優化效果。
盡管如此,我們在使用這種方式時,依然需要考慮的緩存和數據庫一致性問題。
參考資料:
https://albenw.github.io/posts/df42dc84/
本文鏈接:http://www.www897cc.com/showinfo-26-57379-0.htmlGuava Cache 異步刷新技巧,你值得擁有!
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 突破 Pytorch 核心點,損失函數 ?。。?/a>
下一篇: 性能篇:String慎重使用正則表達式?