一個(gè)架構(gòu)師的緩存修煉之路

時(shí)間：2020-11-18 09:27:51

關(guān)鍵字：架構(gòu) 嵌入式

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]一位七牛的資深架構(gòu)師曾經(jīng)說過這樣一句話：Nginx+業(yè)務(wù)邏輯層+數(shù)據(jù)庫+緩存層+消息隊(duì)列，這種模型幾乎能適配絕大部分的業(yè)務(wù)場景。這么多年過去了，這句話或深或淺地影響了我的技術(shù)選擇，以至于后來我花了很多時(shí)間去重點(diǎn)學(xué)習(xí)緩存相關(guān)的技術(shù)。我在10年前開始使用緩存，從本地緩存、到分布式緩存、再到多級緩存，踩過很多坑。下面我結(jié)合自己使用緩存的歷程，談?wù)勎覍彺娴恼J(rèn)識。

一位七牛的資深架構(gòu)師曾經(jīng)說過這樣一句話：

“
Nginx+業(yè)務(wù)邏輯層+數(shù)據(jù)庫+緩存層+消息隊(duì)列，這種模型幾乎能適配絕大部分的業(yè)務(wù)場景。

這么多年過去了，這句話或深或淺地影響了我的技術(shù)選擇，以至于后來我花了很多時(shí)間去重點(diǎn)學(xué)習(xí)緩存相關(guān)的技術(shù)。

我在10年前開始使用緩存，從本地緩存、到分布式緩存、再到多級緩存，踩過很多坑。下面我結(jié)合自己使用緩存的歷程，談?wù)勎覍彺娴恼J(rèn)識。

01?本地緩存

1. 頁面級緩存

我使用緩存的時(shí)間很早，2010年左右使用過 OSCache，當(dāng)時(shí)主要用在 JSP 頁面中用于實(shí)現(xiàn)頁面級緩存。偽代碼類似這樣：

"foobar"?scope="session">?
??????some jsp?content?

中間的那段 JSP 代碼將會以 key="foobar" 緩存在 session 中，這樣其他頁面就能共享這段緩存內(nèi)容。在使用 JSP 這種遠(yuǎn)古技術(shù)的場景下，通過引入 OSCache 之后，頁面的加載速度確實(shí)提升很快。

但隨著前后端分離以及分布式緩存的興起，服務(wù)端的頁面級緩存已經(jīng)很少使用了。但是在前端領(lǐng)域，頁面級緩存仍然很流行。

2. 對象緩存

2011年左右，開源中國的紅薯哥寫了很多篇關(guān)于緩存的文章。他提到：開源中國每天百萬的動(dòng)態(tài)請求，只用 1 臺 4 Core 8G 的服務(wù)器就扛住了，得益于緩存框架 Ehcache。

這讓我非常神往，一個(gè)簡單的框架竟能將單機(jī)性能做到如此這般，讓我欲欲躍試。于是，我參考紅薯哥的示例代碼，在公司的余額提現(xiàn)服務(wù)上第一次使用了 Ehcache。

邏輯也很簡單，就是將成功或者失敗狀態(tài)的訂單緩存起來，這樣下次查詢的時(shí)候，不用再查詢支付寶服務(wù)了。偽代碼類似這樣：

一個(gè)架構(gòu)師的緩存修煉之路

添加緩存之后，優(yōu)化的效果很明顯 , 任務(wù)耗時(shí)從原來的40分鐘減少到了5~10分鐘。

上面這個(gè)示例就是典型的「對象緩存」，它是本地緩存最常見的應(yīng)用場景。相比頁面緩存，它的粒度更細(xì)、更靈活，常用來緩存很少變化的數(shù)據(jù)，比如：全局配置、狀態(tài)已完結(jié)的訂單等，用于提升整體的查詢速度。

3. 刷新策略

2018年，我和我的小伙伴自研了配置中心，為了讓客戶端以最快的速度讀取配置，本地緩存使用了 Guava，整體架構(gòu)如下圖所示：

一個(gè)架構(gòu)師的緩存修煉之路

那本地緩存是如何更新的呢？有兩種機(jī)制：

客戶端啟動(dòng)定時(shí)任務(wù)，從配置中心拉取數(shù)據(jù)。
當(dāng)配置中心有數(shù)據(jù)變化時(shí)，主動(dòng)推送給客戶端。這里我并沒有使用websocket，而是使用了 RocketMQ Remoting 通訊框架。

后來我閱讀了 Soul 網(wǎng)關(guān)的源碼，它的本地緩存更新機(jī)制如下圖所示，共支持 3 種策略：

▍zookeeper watch機(jī)制

soul-admin 在啟動(dòng)的時(shí)候，會將數(shù)據(jù)全量寫入 zookeeper，后續(xù)數(shù)據(jù)發(fā)生變更時(shí)，會增量更新 zookeeper 的節(jié)點(diǎn)。與此同時(shí)，soul-web 會監(jiān)聽配置信息的節(jié)點(diǎn)，一旦有信息變更時(shí)，會更新本地緩存。

▍websocket 機(jī)制

websocket 和 zookeeper 機(jī)制有點(diǎn)類似，當(dāng)網(wǎng)關(guān)與 admin 首次建立好 websocket 連接時(shí)，admin 會推送一次全量數(shù)據(jù)，后續(xù)如果配置數(shù)據(jù)發(fā)生變更，則將增量數(shù)據(jù)通過 websocket 主動(dòng)推送給 soul-web。

▍http 長輪詢機(jī)制

http請求到達(dá)服務(wù)端后，并不是馬上響應(yīng)，而是利用 Servlet 3.0 的異步機(jī)制響應(yīng)數(shù)據(jù)。當(dāng)配置發(fā)生變化時(shí)，服務(wù)端會挨個(gè)移除隊(duì)列中的長輪詢請求，告知是哪個(gè) Group 的數(shù)據(jù)發(fā)生了變更，網(wǎng)關(guān)收到響應(yīng)后，再次請求該 Group 的配置數(shù)據(jù)。

不知道大家發(fā)現(xiàn)了沒？

pull 模式必不可少
增量推送大同小異

長輪詢是一個(gè)有意思的話題 , 這種模式在 RocketMQ 的消費(fèi)者模型也同樣被使用，接近準(zhǔn)實(shí)時(shí)，并且可以減少服務(wù)端的壓力。

02 分布式緩存

關(guān)于分布式緩存, memcached 和 Redis 應(yīng)該是最常用的技術(shù)選型。相信程序員朋友都非常熟悉了，我這里分享兩個(gè)案例。

1.? 合理控制對象大小及讀取策略

2013年，我服務(wù)一家彩票公司，我們的比分直播模塊也用到了分布式緩存。當(dāng)時(shí)，遇到了一個(gè) Young GC 頻繁的線上問題，通過 jstat 工具排查后，發(fā)現(xiàn)新生代每隔兩秒就被占滿了。

進(jìn)一步定位分析，原來是某些 key 緩存的 value 太大了，平均在 300K左右，最大的達(dá)到了500K。這樣在高并發(fā)下，就很容易導(dǎo)致 GC 頻繁。

找到了根本原因后，具體怎么改呢？我當(dāng)時(shí)也沒有清晰的思路。于是，我去同行的網(wǎng)站上研究他們是怎么實(shí)現(xiàn)相同功能的，包括： 360彩票，澳客網(wǎng)。我發(fā)現(xiàn)了兩點(diǎn)：

1、數(shù)據(jù)格式非常精簡，只返回給前端必要的數(shù)據(jù)，部分?jǐn)?shù)據(jù)通過數(shù)組的方式返回

2、使用 websocket，進(jìn)入頁面后推送全量數(shù)據(jù)，數(shù)據(jù)發(fā)生變化推送增量數(shù)據(jù)

再回到我的問題上，最終是用什么方案解決的呢？當(dāng)時(shí)，我們的比分直播模塊緩存格式是 JSON 數(shù)組，每個(gè)數(shù)組元素包含 20 多個(gè)鍵值對, 下面的 JSON 示例我僅僅列了其中 4 個(gè)屬性。

[{ "playId":"2399", "guestTeamName":"小牛", "hostTeamName":"湖人", "europe":"123" }]

這種數(shù)據(jù)結(jié)構(gòu)，一般情況下沒有什么問題。但是當(dāng)字段數(shù)多達(dá) 20 多個(gè)，而且每天的比賽場次非常多時(shí)，在高并發(fā)的請求下其實(shí)很容易引發(fā)問題。

基于工期以及風(fēng)險(xiǎn)考慮，最終我們采用了比較保守的優(yōu)化方案：

1）修改新生代大小，從原來的 2G 修改成 4G

2）將緩存數(shù)據(jù)的格式由 JSON 改成數(shù)組，如下所示：

[["2399","小牛","湖人","123"]]

修改完成之后, 緩存的大小從平均 300k 左右降為 80k 左右，YGC 頻率下降很明顯，同時(shí)頁面響應(yīng)也變快了很多。

但過了一會，cpu load 會在瞬間波動(dòng)得比較高?？梢姡m然我們減少了緩存大小，但是讀取大對象依然對系統(tǒng)資源是極大的損耗，導(dǎo)致 Full GC 的頻率也不低。?

3）為了徹底解決這個(gè)問題，我們使用了更精細(xì)化的緩存讀取策略。

我們把緩存拆成兩個(gè)部分，第一部分是全量數(shù)據(jù)，第二部分是增量數(shù)據(jù)（數(shù)據(jù)量很小）。頁面第一次請求拉取全量數(shù)據(jù)，當(dāng)比分有變化的時(shí)候，通過 websocket 推送增量數(shù)據(jù)。

第 3 步完成后，頁面的訪問速度極快，服務(wù)器的資源使用也很少，優(yōu)化的效果非常優(yōu)異。

經(jīng)過這次優(yōu)化，我理解到:? 緩存雖然可以提升整體速度，但是在高并發(fā)場景下，緩存對象大小依然是需要關(guān)注的點(diǎn)，稍不留神就會產(chǎn)生事故。另外我們也需要合理地控制讀取策略，最大程度減少 GC 的頻率 , 從而提升整體性能。

2.? 分頁列表查詢

列表如何緩存是我非常渴望和大家分享的技能點(diǎn)。這個(gè)知識點(diǎn)也是我 2012 年從開源中國上學(xué)到的，下面我以「查詢博客列表」的場景為例。

我們先說第 1 種方案：對分頁內(nèi)容進(jìn)行整體緩存。這種方案會按照頁碼和每頁大小組合成一個(gè)緩存key，緩存值就是博客信息列表。假如某一個(gè)博客內(nèi)容發(fā)生修改, 我們要重新加載緩存，或者刪除整頁的緩存。

這種方案，緩存的顆粒度比較大，如果博客更新較為頻繁，則緩存很容易失效。下面我介紹下第 2 種方案：僅對博客進(jìn)行緩存。流程大致如下：

1）先從數(shù)據(jù)庫查詢當(dāng)前頁的博客id列表，sql類似:

select?id?from?blogs?limit?0,10?

2）批量從緩存中獲取博客id列表對應(yīng)的緩存數(shù)據(jù) ，并記錄沒有命中的博客id，若沒有命中的id列表大于0，再次從數(shù)據(jù)庫中查詢一次，并放入緩存，sql類似：

select?id?from?blogs?where?id?in?(noHitId1,?noHitId2)

3）將沒有緩存的博客對象存入緩存中

4）返回博客對象列表

理論上，要是緩存都預(yù)熱的情況下，一次簡單的數(shù)據(jù)庫查詢，一次緩存批量獲取，即可返回所有的數(shù)據(jù)。另外，關(guān)于緩存批量獲取，如何實(shí)現(xiàn)？

本地緩存：性能極高，for 循環(huán)即可
memcached：使用 mget 命令
Redis：若緩存對象結(jié)構(gòu)簡單，使用 mget 、hmget命令；若結(jié)構(gòu)復(fù)雜，可以考慮使用 pipleline，lua腳本模式

第 1 種方案適用于數(shù)據(jù)極少發(fā)生變化的場景，比如排行榜，首頁新聞資訊等。

第 2 種方案適用于大部分的分頁場景，而且能和其他資源整合在一起。舉例：在搜索系統(tǒng)里，我們可以通過篩選條件查詢出博客 id 列表，然后通過如上的方式，快速獲取博客列表。

03 多級緩存

首先要明確為什么要使用多級緩存？

本地緩存速度極快，但是容量有限，而且無法共享內(nèi)存。分布式緩存容量可擴(kuò)展，但在高并發(fā)場景下，如果所有數(shù)據(jù)都必須從遠(yuǎn)程緩存種獲取，很容易導(dǎo)致帶寬跑滿，吞吐量下降。

有句話說得好，緩存離用戶越近越高效！

使用多級緩存的好處在于：高并發(fā)場景下, 能提升整個(gè)系統(tǒng)的吞吐量，減少分布式緩存的壓力。

2018年，我服務(wù)的一家電商公司需要進(jìn)行 app 首頁接口的性能優(yōu)化。我花了大概兩天的時(shí)間完成了整個(gè)方案，采取的是兩級緩存模式，同時(shí)利用了 guava 的惰性加載機(jī)制，整體架構(gòu)如下圖所示：

一個(gè)架構(gòu)師的緩存修煉之路

緩存讀取流程如下：

1、業(yè)務(wù)網(wǎng)關(guān)剛啟動(dòng)時(shí)，本地緩存沒有數(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ī)制，每隔一段時(shí)間會調(diào)用自定義 LoadingCache 線程池（5個(gè)最大線程，5個(gè)核心線程）去導(dǎo)購服務(wù)同步數(shù)據(jù)到本地緩存和 Redis 中。

優(yōu)化后，性能表現(xiàn)很好，平均耗時(shí)在 5ms 左右。最開始我以為出現(xiàn)問題的幾率很小，可是有一天晚上，突然發(fā)現(xiàn) app 端首頁顯示的數(shù)據(jù)時(shí)而相同，時(shí)而不同。

也就是說：?雖然 LoadingCache 線程一直在調(diào)用接口更新緩存信息，但是各個(gè) 服務(wù)器本地緩存中的數(shù)據(jù)并非完成一致。說明了兩個(gè)很重要的點(diǎn)： ?

1、惰性加載仍然可能造成多臺機(jī)器的數(shù)據(jù)不一致

2、 LoadingCache 線程池?cái)?shù)量配置的不太合理,? 導(dǎo)致了線程堆積

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

1、惰性加載結(jié)合消息機(jī)制來更新緩存數(shù)據(jù)，也就是：當(dāng)導(dǎo)購服務(wù)的配置發(fā)生變化時(shí)，通知業(yè)務(wù)網(wǎng)關(guān)重新拉取數(shù)據(jù)，更新緩存。

2、適當(dāng)調(diào)大 LoadigCache 的線程池參數(shù)，并在線程池埋點(diǎn)，監(jiān)控線程池的使用情況，當(dāng)線程繁忙時(shí)能發(fā)出告警，然后動(dòng)態(tài)修改線程池參數(shù)。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

一個(gè)架構(gòu)師的緩存修煉之路

長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！