一位七牛的資深架構(gòu)師曾經(jīng)說過這樣一句話：
“Nginx+業(yè)務(wù)邏輯層+數(shù)據(jù)庫+緩存層+消息隊列，這種模型幾乎能適配絕大部分的業(yè)務(wù)場景。
這么多年過去了，這句話或深或淺地影響了我的技術(shù)選擇，以至于后來我花了很多時間去重點(diǎn)學(xué)習(xí)緩存相關(guān)的技術(shù)。
我在10年前開始使用緩存，從本地緩存、到分布式緩存、再到多級緩存，踩過很多坑。下面我結(jié)合自己使用緩存的歷程，談?wù)勎覍彺娴恼J(rèn)識。
01?本地緩存
1. 頁面級緩存
"foobar" ??????some jsp?content?
2. 對象緩存
3. 刷新策略
2018年，我和我的小伙伴自研了配置中心，為了讓客戶端以最快的速度讀取配置， 本地緩存使用了 Guava，整體架構(gòu)如下圖所示：
那本地緩存是如何更新的呢？有兩種機(jī)制：
-
客戶端啟動定時任務(wù)，從配置中心拉取數(shù)據(jù)。 -
當(dāng)配置中心有數(shù)據(jù)變化時，主動推送給客戶端。這里我并沒有使用websocket，而是使用了 RocketMQ Remoting 通訊框架。
▍zookeeper watch機(jī)制
▍websocket 機(jī)制
websocket 和 zookeeper 機(jī)制有點(diǎn)類似，當(dāng)網(wǎng)關(guān)與 admin 首次建立好 websocket 連接時，admin 會推送一次全量數(shù)據(jù)，后續(xù)如果配置數(shù)據(jù)發(fā)生變更，則將增量數(shù)據(jù)通過 websocket 主動推送給 soul-web。
http請求到達(dá)服務(wù)端后，并不是馬上響應(yīng)，而是利用 Servlet 3.0 的異步機(jī)制響應(yīng)數(shù)據(jù)。當(dāng)配置發(fā)生變化時，服務(wù)端會挨個移除隊列中的長輪詢請求，告知是哪個 Group 的數(shù)據(jù)發(fā)生了變更，網(wǎng)關(guān)收到響應(yīng)后，再次請求該 Group 的配置數(shù)據(jù)。
-
pull 模式必不可少 -
增量推送大同小異
02 分布式緩存
1.? 合理控制對象大小及讀取策略
1、數(shù)據(jù)格式非常精簡，只返回給前端必要的數(shù)據(jù)，部分?jǐn)?shù)據(jù)通過數(shù)組的方式返回
2、使用 websocket，進(jìn)入頁面后推送全量數(shù)據(jù)，數(shù)據(jù)發(fā)生變化推送增量數(shù)據(jù)
再回到我的問題上，最終是用什么方案解決的呢？當(dāng)時，我們的比分直播模塊緩存格式是 JSON 數(shù)組，每個數(shù)組元素包含 20 多個鍵值對, 下面的 JSON 示例我僅僅列了其中 4 個屬性。
[{"playId":"2399","guestTeamName":"小牛","hostTeamName":"湖人","europe":"123"}]
這種數(shù)據(jù)結(jié)構(gòu)，一般情況下沒有什么問題。但是當(dāng)字段數(shù)多達(dá) 20 多個，而且每天的比賽場次非常多時，在高并發(fā)的請求下其實(shí)很容易引發(fā)問題。
基于工期以及風(fēng)險考慮，最終我們采用了比較保守的優(yōu)化方案：
[["2399","小牛","湖人","123"]]修改完成之后, 緩存的大小從平均 300k 左右降為 80k 左右，YGC 頻率下降很明顯，同時頁面響應(yīng)也變快了很多。
但過了一會，cpu load 會在瞬間波動得比較高?？梢?，雖然我們減少了緩存大小，但是讀取大對象依然對系統(tǒng)資源是極大的損耗，導(dǎo)致 Full GC 的頻率也不低。?
3）為了徹底解決這個問題，我們使用了更精細(xì)化的緩存讀取策略。
我們把緩存拆成兩個部分，第一部分是全量數(shù)據(jù)，第二部分是增量數(shù)據(jù)（數(shù)據(jù)量很?。?。頁面第一次請求拉取全量數(shù)據(jù)，當(dāng)比分有變化的時候，通過 websocket 推送增量數(shù)據(jù)。
第 3 步完成后，頁面的訪問速度極快，服務(wù)器的資源使用也很少，優(yōu)化的效果非常優(yōu)異。
2.? 分頁列表查詢
select?id?from?blogs?limit?0,10?select?id?from?blogs?where?id?in?(noHitId1,?noHitId2)-
本地緩存：性能極高，for 循環(huán)即可 -
memcached：使用 mget 命令 -
Redis：若緩存對象結(jié)構(gòu)簡單，使用 mget 、hmget命令；若結(jié)構(gòu)復(fù)雜，可以考慮使用 pipleline，lua腳本模式
03 多級緩存
緩存讀取流程如下：
1、業(yè)務(wù)網(wǎng)關(guān)剛啟動時，本地緩存沒有數(shù)據(jù)，讀取 Redis 緩存，如果 Redis 緩存也沒數(shù)據(jù)，則通過 RPC 調(diào)用導(dǎo)購服務(wù)讀取數(shù)據(jù)，然后再將數(shù)據(jù)寫入本地緩存和 Redis 中；若 Redis 緩存不為空，則將緩存數(shù)據(jù)寫入本地緩存中。
2、由于步驟1已經(jīng)對本地緩存預(yù)熱，后續(xù)請求直接讀取本地緩存，返回給用戶端。
3、Guava 配置了 refresh 機(jī)制，每隔一段時間會調(diào)用自定義 LoadingCache 線程池（5個最大線程，5個核心線程）去導(dǎo)購服務(wù)同步數(shù)據(jù)到本地緩存和 Redis 中。
優(yōu)化后，性能表現(xiàn)很好，平均耗時在 5ms 左右。最開始我以為出現(xiàn)問題的幾率很小，可是有一天晚上，突然發(fā)現(xiàn) app 端首頁顯示的數(shù)據(jù)時而相同，時而不同。
1、惰性加載仍然可能造成多臺機(jī)器的數(shù)據(jù)不一致
2、 LoadingCache 線程池數(shù)量配置的不太合理,? 導(dǎo)致了線程堆積
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點(diǎn)個在看，誠摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點(diǎn)，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
