Guava Cache是一款非常優(yōu)秀的本地緩存框架。

創(chuàng)新互聯(lián)建站始終堅持【策劃先行，效果至上】的經(jīng)營理念，通過多達10年累計超上千家客戶的網(wǎng)站建設總結(jié)了一套系統(tǒng)有效的網(wǎng)絡營銷推廣解決方案，現(xiàn)已廣泛運用于各行各業(yè)的客戶，其中包括：成都發(fā)電機維修等企業(yè)，備受客戶好評。

這篇文章，我們聊聊如何使用 Guava Cache 異步刷新技巧帶飛系統(tǒng)性能 。

圖片

1 經(jīng)典配置

Guava Cache 的數(shù)據(jù)結(jié)構跟 JDK1.7 的 ConcurrentHashMap 類似，提供了基于時間、容量、引用三種回收策略，以及自動加載、訪問統(tǒng)計等功能。

圖片

首先，我們溫習下 Gauva Cache 的經(jīng)典配置 。

圖片

例子中，緩存最大容量設置為 100 （基于容量進行回收），配置了失效策略和刷新策略。

• 失效策略

配置 expireAfterWrite 后，緩存項在被創(chuàng)建或最后一次更新后的指定時間內(nèi)會過期。

• 刷新策略

配置 refreshAfterWrite 設置刷新時間，當緩存項過期的同時可以重新加載新值 。

這個例子里，有的同學可能會有疑問：為什么需要配置刷新策略，只配置失效策略不就可以嗎？

當然是可以的，但在高并發(fā)場景下，配置刷新策略會有奇效，接下來，我們會寫一個測試用例，方便大家理解 Gauva Cache 的線程模型。

2  理解線程模型

我們模擬在多線程場景下，「緩存過期執(zhí)行 load 方法」和「刷新執(zhí)行 reload 方法」兩者的運行情況。

圖片

執(zhí)行結(jié)果見下圖：

圖片

執(zhí)行結(jié)果表明：Guava Cache 并沒有后臺任務線程異步的執(zhí)行 load 或者 reload 方法。

失效策略：expireAfterWrite 允許一個線程執(zhí)行 load 方法，其他線程阻塞等待 。當大量線程用相同的 key 獲取緩存值時，只會有一個線程進入 load 方法，而其他線程則等待，直到緩存值被生成。這樣也就避免了緩存擊穿的危險。高并發(fā)場景下 ，這樣還是會阻塞大量線程。

刷新策略：refreshAfterWrite 允許一個線程執(zhí)行 load 方法，其他線程返回舊的值。單個 key 并發(fā)下，使用 refreshAfterWrite ，雖然不會阻塞了，但是如果恰巧同時多個 key 同時過期，還是會給數(shù)據(jù)庫造成壓力。

為了提升系統(tǒng)性能，我們可以從如下兩個方面來優(yōu)化 ：

1. 配置  refresh < expire ，減少大量線程阻塞的概率；
2. 采用異步刷新的策略，也就是線程異步加載數(shù)據(jù)，期間所有請求返回舊的緩存值，防止緩存雪崩。

下圖展示優(yōu)化方案的時間軸 ：

圖片

3 兩種方式實現(xiàn)異步刷新

3.1 重寫 reload 方法

圖片

3.2 實現(xiàn) asyncReloading 方法

圖片

不管使用哪種方案， 都需要定義單獨的線程池來執(zhí)行刷新任務 。

4 異步刷新 + 多級緩存

2018 年，筆者服務的一家電商公司需要進行 app 首頁接口的性能優(yōu)化。筆者花了大概兩天的時間完成了整個方案，采取的是兩級緩存模式，同時采用了 Guava 的異步刷新機制。

整體架構如下圖所示：

圖片

緩存讀取流程如下 ：

• 業(yè)務網(wǎng)關剛啟動時，本地緩存沒有數(shù)據(jù)，讀取 Redis 緩存，如果 Redis 緩存也沒數(shù)據(jù)，則通過 RPC 調(diào)用導購服務讀取數(shù)據(jù)，然后再將數(shù)據(jù)寫入本地緩存和 Redis 中；若 Redis 緩存不為空，則將緩存數(shù)據(jù)寫入本地緩存中。
• 由于步驟1已經(jīng)對本地緩存預熱，后續(xù)請求直接讀取本地緩存，返回給用戶端。
• Guava 配置了 refresh 機制，每隔一段時間會調(diào)用自定義 LoadingCache 線程池（5個最大線程，5個核心線程）去導購服務同步數(shù)據(jù)到本地緩存和 Redis 中。

優(yōu)化后，性能表現(xiàn)很好，平均耗時在 5ms 左右，同時大幅度的減少應用 GC 的頻率。

該方案依然有瑕疵，一天晚上我們發(fā)現(xiàn) app 端首頁顯示的數(shù)據(jù)時而相同，時而不同。

也就是說：雖然 LoadingCache 線程一直在調(diào)用接口更新緩存信息，但是各個服務器本地緩存中的數(shù)據(jù)并非完成一致。

這說明了兩個很重要的點：

• 惰性加載仍然可能造成多臺機器的數(shù)據(jù)不一致；
• LoadingCache 線程池數(shù)量配置的不太合理,  導致了任務堆積。

最終，我們的解決方案是：

• 異步刷新結(jié)合消息機制來更新緩存數(shù)據(jù)，也就是：當導購服務的配置發(fā)生變化時，通知業(yè)務網(wǎng)關重新拉取數(shù)據(jù)，更新緩存。
• 適當調(diào)大 LoadingCache 的線程池參數(shù)，并在線程池埋點，監(jiān)控線程池的使用情況，當線程繁忙時能發(fā)出告警，然后動態(tài)修改線程池參數(shù)。

5 總結(jié)

Guava Cache 非常強大，它并沒有后臺任務線程異步的執(zhí)行 load 或者 reload 方法，而是通過請求線程來執(zhí)行相關操作。

為了提升系統(tǒng)性能，我們可以從如下兩個方面來處理 ：

• 配置 refresh < expire，減少大量線程阻塞的概率。
• 采用異步刷新的策略，也就是線程異步加載數(shù)據(jù)，期間所有請求返回舊的緩存值。

筆者曾經(jīng)優(yōu)化過某電商網(wǎng)站的首頁接口，使用的方案是：Guava 的異步刷新機制 + 多級緩存 ，取得了非常好的優(yōu)化效果。

盡管如此，我們在使用這種方式時，依然需要考慮的緩存和數(shù)據(jù)庫一致性問題。

參考資料：

https://albenw.github.io/posts/df42dc84/

文章名稱：GuavaCache異步刷新技巧，你值得擁有!
本文來源：http://uogjgqi.cn/article/cogescc.html