一個架構(gòu)師的緩存修煉之路
本文作者：張勇，現(xiàn)任科大訊飛高級架構(gòu)師。11年后端經(jīng)驗，曾就職于同程藝龍、神州優(yōu)車等公司。樂于分享、熱衷通過自己的實踐經(jīng)驗平鋪對技術(shù)的理解。
“Nginx+業(yè)務(wù)邏輯層+數(shù)據(jù)庫+緩存層+消息隊列，這種模型幾乎能適配絕大部分的業(yè)務(wù)場景。
這么多年過去了，這句話或深或淺地影響了我的技術(shù)選擇，以至于后來我花了很多時間去重點學習緩存相關(guān)的技術(shù)。
我在10年前開始使用緩存，從本地緩存、到分布式緩存、再到多級緩存，踩過很多坑。下面我結(jié)合自己使用緩存的歷程，談?wù)勎覍彺娴恼J識。
01?本地緩存
1. 頁面級緩存
"foobar" ??????some jsp?content?
2. 對象緩存
3. 刷新策略
2018年，我和我的小伙伴自研了配置中心，為了讓客戶端以最快的速度讀取配置， 本地緩存使用了 Guava，整體架構(gòu)如下圖所示：
那本地緩存是如何更新的呢？有兩種機制：
客戶端啟動定時任務(wù)，從配置中心拉取數(shù)據(jù)。 當配置中心有數(shù)據(jù)變化時，主動推送給客戶端。這里我并沒有使用websocket，而是使用了 RocketMQ Remoting 通訊框架。
▍zookeeper watch機制
▍websocket 機制
websocket 和 zookeeper 機制有點類似，當網(wǎng)關(guān)與 admin 首次建立好 websocket 連接時，admin 會推送一次全量數(shù)據(jù)，后續(xù)如果配置數(shù)據(jù)發(fā)生變更，則將增量數(shù)據(jù)通過 websocket 主動推送給 soul-web。
http請求到達服務(wù)端后，并不是馬上響應(yīng)，而是利用 Servlet 3.0 的異步機制響應(yīng)數(shù)據(jù)。當配置發(fā)生變化時，服務(wù)端會挨個移除隊列中的長輪詢請求，告知是哪個 Group 的數(shù)據(jù)發(fā)生了變更，網(wǎng)關(guān)收到響應(yīng)后，再次請求該 Group 的配置數(shù)據(jù)。
pull 模式必不可少 增量推送大同小異
02 分布式緩存
1.? 合理控制對象大小及讀取策略
1、數(shù)據(jù)格式非常精簡，只返回給前端必要的數(shù)據(jù)，部分數(shù)據(jù)通過數(shù)組的方式返回
2、使用 websocket，進入頁面后推送全量數(shù)據(jù)，數(shù)據(jù)發(fā)生變化推送增量數(shù)據(jù)
再回到我的問題上，最終是用什么方案解決的呢？當時，我們的比分直播模塊緩存格式是 JSON 數(shù)組，每個數(shù)組元素包含 20 多個鍵值對, 下面的 JSON 示例我僅僅列了其中 4 個屬性。
[{"playId":"2399","guestTeamName":"小牛","hostTeamName":"湖人","europe":"123"}]
這種數(shù)據(jù)結(jié)構(gòu)，一般情況下沒有什么問題。但是當字段數(shù)多達 20 多個，而且每天的比賽場次非常多時，在高并發(fā)的請求下其實很容易引發(fā)問題。
基于工期以及風險考慮，最終我們采用了比較保守的優(yōu)化方案：
[["2399","小牛","湖人","123"]]修改完成之后, 緩存的大小從平均 300k 左右降為 80k 左右，YGC 頻率下降很明顯，同時頁面響應(yīng)也變快了很多。
但過了一會，cpu load 會在瞬間波動得比較高。可見，雖然我們減少了緩存大小，但是讀取大對象依然對系統(tǒng)資源是極大的損耗，導致 Full GC 的頻率也不低。?
3）為了徹底解決這個問題，我們使用了更精細化的緩存讀取策略。
我們把緩存拆成兩個部分，第一部分是全量數(shù)據(jù)，第二部分是增量數(shù)據(jù)（數(shù)據(jù)量很小）。頁面第一次請求拉取全量數(shù)據(jù)，當比分有變化的時候，通過 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)復雜，可以考慮使用 pipleline，lua腳本模式
03 多級緩存
緩存讀取流程如下：
1、業(yè)務(wù)網(wǎng)關(guān)剛啟動時，本地緩存沒有數(shù)據(jù)，讀取 Redis 緩存，如果 Redis 緩存也沒數(shù)據(jù)，則通過 RPC 調(diào)用導購服務(wù)讀取數(shù)據(jù)，然后再將數(shù)據(jù)寫入本地緩存和 Redis 中；若 Redis 緩存不為空，則將緩存數(shù)據(jù)寫入本地緩存中。
2、由于步驟1已經(jīng)對本地緩存預(yù)熱，后續(xù)請求直接讀取本地緩存，返回給用戶端。
3、Guava 配置了 refresh 機制，每隔一段時間會調(diào)用自定義 LoadingCache 線程池（5個最大線程，5個核心線程）去導購服務(wù)同步數(shù)據(jù)到本地緩存和 Redis 中。
優(yōu)化后，性能表現(xiàn)很好，平均耗時在 5ms 左右。最開始我以為出現(xiàn)問題的幾率很小，可是有一天晚上，突然發(fā)現(xiàn) app 端首頁顯示的數(shù)據(jù)時而相同，時而不同。
1、惰性加載仍然可能造成多臺機器的數(shù)據(jù)不一致
2、 LoadingCache 線程池數(shù)量配置的不太合理,? 導致了線程堆積
緩存是非常重要的一個技術(shù)手段。如果能從原理到實踐，不斷深入地去掌握它，這應(yīng)該是技術(shù)人員最享受的事情。
這篇文章屬于緩存系列的開篇，更多是把我 10 多年工作中遇到的典型問題娓娓道來，并沒有非常深入地去探討原理性的知識。
我想我更應(yīng)該和朋友交流的是：如何體系化的學習一門新技術(shù)。
選擇該技術(shù)的經(jīng)典書籍，理解基礎(chǔ)概念? 建立該技術(shù)的知識脈絡(luò)? 知行合一，在生產(chǎn)環(huán)境中實踐或者自己造輪子 不斷復盤，思考是否有更優(yōu)的方案
后續(xù)我會連載一些緩存相關(guān)的內(nèi)容：包括緩存的高可用機制、codis 的原理等，歡迎大家繼續(xù)關(guān)注。
關(guān)于緩存，如果你有自己的心得體會或者想深入了解的內(nèi)容，歡迎評論區(qū)留言。
大家在看：
IT人的職場進階?
前亞馬遜工程師，現(xiàn)58轉(zhuǎn)轉(zhuǎn)技術(shù)總監(jiān)，持續(xù)分享個人的成長經(jīng)歷，希望為你的職場發(fā)展帶來些新思路，歡迎掃碼關(guān)注我！