今天我們來(lái)聊聊緩存這個(gè)話題，看看在微服務(wù)環(huán)境下如何設(shè)計(jì)有效的多級(jí)緩存架構(gòu)。主要涉及三方面內(nèi)容：

Web 應(yīng)用的客戶(hù)端緩存；

應(yīng)用層靜態(tài)資源緩存；

服務(wù)層多級(jí)緩存。

首先，咱們先講解微服務(wù)架構(gòu)的多級(jí)緩存設(shè)計(jì)。

微服務(wù)架構(gòu)中的多級(jí)緩存設(shè)計(jì)

提到緩存，想必每一位軟件工程師都不陌生，它是目前架構(gòu)設(shè)計(jì)中提高性能最直接的方式。這里我們舉個(gè)例子：

假設(shè)應(yīng)用程序?qū)⒃紨?shù)據(jù)存儲(chǔ)在 MySQL 數(shù)據(jù)庫(kù)中。眾所周知 MySQL 數(shù)據(jù)庫(kù)會(huì)將數(shù)據(jù)存儲(chǔ)在硬盤(pán)以防止掉電丟失，但是受制于硬盤(pán)的物理設(shè)計(jì)，即便是目前性能最好的企業(yè)級(jí) SSD 硬盤(pán)，也比內(nèi)存的這種高速設(shè)備 IO 層面差一個(gè)數(shù)量級(jí)，而以淘寶、京東這種電商為代表的互聯(lián)網(wǎng)應(yīng)用，都是典型的 “讀多寫(xiě)少” 的場(chǎng)景，因此我們需要在設(shè)計(jì)上進(jìn)行數(shù)據(jù)的讀寫(xiě)分離，在數(shù)據(jù)寫(xiě)入時(shí)直接落盤(pán)處理，而占比超過(guò) 90% 的數(shù)據(jù)讀取操作時(shí)則從以 Redis 為代表的內(nèi)存 NoSQL 數(shù)據(jù)庫(kù)提取數(shù)據(jù)，利用內(nèi)存的高吞吐瞬間完成數(shù)據(jù)提取，這里 Redis 的作用就是我們常說(shuō)的緩存。

當(dāng)然，緩存可不只有用內(nèi)存替代硬盤(pán)這一種形式，在分布式架構(gòu)下緩存在每一層都有自己的設(shè)計(jì)，下面咱們通過(guò)這個(gè)微服務(wù)的多級(jí)緩存架構(gòu)圖為主線進(jìn)行講解。

這張圖從上到下包含四層，分別為：客戶(hù)端、應(yīng)用層、服務(wù)層以及數(shù)據(jù)層。

客戶(hù)端緩存

X 商城客戶(hù)端為瀏覽器，在瀏覽器層面我們主要是對(duì) HTML 中的圖片、CSS、JS、字體這些靜態(tài)資源進(jìn)行緩存。

我們以百度 Logo 圖片為例，百度在 HTTP 通過(guò) Expires 響應(yīng)頭控制靜態(tài)圖片的有效期。Expires 代表過(guò)期時(shí)間。當(dāng)前百度 Logo 的過(guò)期時(shí)間為 2031 年 2 月 8 日 9 時(shí) 26 分 31 秒。在這個(gè)時(shí)間段內(nèi)，瀏覽器會(huì)將圖片以文件形式緩存在本地，再次訪問(wèn)時(shí)會(huì)看到“from disk cache”的提示，此時(shí)瀏覽器不再產(chǎn)生與服務(wù)器的實(shí)際請(qǐng)求，會(huì)從本地直接讀取緩存圖片。通過(guò)在瀏覽器端設(shè)置 Expires 可以在很大程度減少重復(fù)請(qǐng)求靜態(tài)資源帶來(lái)的帶寬損耗，這在高并發(fā) Web 應(yīng)用中是基礎(chǔ)而重要的設(shè)置。

應(yīng)用層緩存

那 Expires 到底在哪里進(jìn)行設(shè)置呢？對(duì)于瀏覽器來(lái)說(shuō)它只是客戶(hù)端，只負(fù)責(zé)讀取 Expires 響應(yīng)頭，對(duì)于 Expires 要在應(yīng)用層，也就是 CDN 與 Nginx 中進(jìn)行設(shè)置。

CDN 內(nèi)容分發(fā)網(wǎng)絡(luò)

CDN 全稱(chēng)是 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)，是互聯(lián)網(wǎng)靜態(tài)資源分發(fā)的主要技術(shù)手段。

CDN 內(nèi)容分發(fā)網(wǎng)絡(luò)

中國(guó)幅員遼闊，從北京到上海就有上千公里，如果大量的上海用戶(hù)同時(shí)要訪問(wèn)千里之外的北京服務(wù)器的資源，這么長(zhǎng)的通信必然帶來(lái)高延遲與更多不可控因素影響數(shù)據(jù)傳輸，如果有某種機(jī)制允許將北京的靜態(tài)文件緩存到上海的服務(wù)器，上海用戶(hù)自動(dòng)就近訪問(wèn)服務(wù)器獲取資源，這樣便可很大程度降低網(wǎng)絡(luò)延遲，進(jìn)而提高系統(tǒng)的可用性。而剛才提到的分布式緩存技術(shù)就是我們常提到的 CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）。

對(duì)于廣域的互聯(lián)網(wǎng)應(yīng)用，CDN 幾乎是必需的基礎(chǔ)設(shè)施，它有效解決了帶寬集中占用以及數(shù)據(jù)分發(fā)的問(wèn)題。像 Web 頁(yè)面中的圖片、音視頻、CSS、JS 這些靜態(tài)資源，都可以通過(guò) CDN 服務(wù)器就近獲取。

CDN 技術(shù)的核心是“智能 DNS”，智能 DNS 會(huì)根據(jù)用戶(hù)的 IP 地址自動(dòng)確定就近訪問(wèn) CDN 節(jié)點(diǎn)，咱們以下圖為例：

以某上海用戶(hù)的瀏覽器要訪問(wèn)商城首頁(yè)廣告位的 banner.jpg 文件，瀏覽器通過(guò)服務(wù)商提供的智能 DNS 服務(wù)，將請(qǐng)求自動(dòng)轉(zhuǎn)發(fā)到商城在上海地區(qū)準(zhǔn)備的 CDN 服務(wù)器，上海 CDN 收到請(qǐng)求后首先檢查本機(jī)是否已緩存過(guò) banner.jpg，如果文件已存在便直接將圖片數(shù)據(jù)返回給客戶(hù)端；如果沒(méi)有緩存過(guò)，則回源到北京的源數(shù)據(jù)節(jié)點(diǎn)，將 banner.jpg 文件抽取并緩存到上海服務(wù)器，最后上海 CDN 節(jié)點(diǎn)再將本機(jī)的 banner.jpg 返回給客戶(hù)端。對(duì)于 banner.jpg 來(lái)說(shuō)，第一次訪問(wèn)后上海 CDN 節(jié)點(diǎn)已緩存該文件，則之后的緩存有效期內(nèi)所有后續(xù)訪問(wèn)由上海 CDN 直接提供。與之類(lèi)似的，商城應(yīng)用可以在重要城市搭建 CDN 節(jié)點(diǎn)，這樣原本集中被發(fā)往北京服務(wù)器的請(qǐng)求就被分?jǐn)偟?CDN 節(jié)點(diǎn)，這也直接降低了北京機(jī)房的帶寬壓力。

在互聯(lián)網(wǎng)應(yīng)用中，因?yàn)?CDN 涉及多地域多節(jié)點(diǎn)組網(wǎng)，前期投入成本較高，更多的中小型軟件公司通常會(huì)選擇阿里云、騰訊云等大廠提供的 CDN 服務(wù)，通過(guò)按需付費(fèi)的方式降低硬件成本。而這些服務(wù)商又會(huì)為 CDN 賦予額外的能力，比如阿里云、騰訊云 CDN 除了緩存文件之外，還提供了管理后臺(tái)能為響應(yīng)賦予額外的響應(yīng)頭。如下所示在阿里云 CDN 后臺(tái)，就額外設(shè)置了 Cache-Control 響應(yīng)頭代表緩存有效期為 1 小時(shí)。這里我們額外提一下 Expires 與的 Cache-Control 的區(qū)別，Expires 是指定具體某個(gè)時(shí)間點(diǎn)緩存到期，而 Cache-Control 則代表緩存的有效期是多長(zhǎng)時(shí)間。Expires 設(shè)置時(shí)間，Cache-Control 設(shè)置時(shí)長(zhǎng)，根據(jù)業(yè)務(wù)場(chǎng)景不同可以使用不同的響應(yīng)頭。

Nginx 緩存管理

說(shuō)完 CDN，下面再來(lái)聊一下 Nginx。Nginx 是一款開(kāi)源的、跨平臺(tái)的高性能 Web 服務(wù)器，它有著高性能，穩(wěn)定性好，配置簡(jiǎn)單，模塊結(jié)構(gòu)化，資源消耗低的優(yōu)點(diǎn)。同時(shí)支持反向代理、負(fù)載均衡、緩存的功能。Nginx 是 Web 應(yīng)用架構(gòu)中的?？停绾蠖?Tomcat 集群便可通過(guò)增加 Nginx 前置做軟負(fù)載均衡，為應(yīng)用提供高可用特性。

在互聯(lián)網(wǎng)應(yīng)用中，用戶(hù)分布在全國(guó)各地，對(duì)資源的響應(yīng)速度與帶寬要求較高，因此部署 CDN 是十分有必要的。但在更多的企業(yè)應(yīng)用中，其實(shí)大部分的企業(yè)用戶(hù)都分布在指定的辦公區(qū)域或者相對(duì)固定的場(chǎng)所，再加上并發(fā)用戶(hù)相對(duì)較少，其實(shí)并不需要額外部署 CDN 這種重量級(jí)解決方案。在架構(gòu)中只需要部署 Nginx 服務(wù)器，利用 Nginx 自帶的靜態(tài)資源緩存與壓縮功能便可勝任大多數(shù)企業(yè)應(yīng)用場(chǎng)景。

在 Nginx 中自帶將后端應(yīng)用中圖片、CSS、JS 等靜態(tài)資源緩存功能，我們只需在 Nginx 的核心配置 nginx.conf 中增加下面的片段，便可對(duì)后端的靜態(tài)資源進(jìn)行緩存，關(guān)鍵配置我已做好注釋?zhuān)瑢W(xué)們可以直接使用。

?

?

#?設(shè)置緩存目錄
#?levels代表采用1:2也就是兩級(jí)目錄的形式保存緩存文件（靜態(tài)資源css、js）
#?keys_zone定義緩存的名稱(chēng)及內(nèi)存的使用，名稱(chēng)為babytun-cache?,在內(nèi)存中開(kāi)始100m交換空間
#?inactive=7d?如果某個(gè)緩存文件超過(guò)7天沒(méi)有被訪問(wèn)，則刪除
#?max_size=20g;代表設(shè)置文件夾最大不能超過(guò)20g，超過(guò)后會(huì)自動(dòng)將訪問(wèn)頻度（命中率）最低的緩存文件刪除
proxy_cache_path?d:/nginx-cache?levels=1:2?keys_zone=babytun-cache:100m?inactive=7d?max_size=20g;

#配置xmall后端服務(wù)器的權(quán)重負(fù)載均衡策略
upstream?xmall?{
????server?192.168.31.181?weight=5?max_fails=1?fail_timeout=3s;
????server?192.168.31.182?weight=2;
????server?192.168.31.183?weight=1;
????server?192.168.31.184?weight=2;
}

server?{
??#nginx通過(guò)80端口提供Web服務(wù)
??listen?80;
??#?開(kāi)啟靜態(tài)資源緩存
??#?利用正則表達(dá)式匹配URL，匹配成功的則執(zhí)行內(nèi)部邏輯
??#?~*?代表URL匹配不區(qū)分大小寫(xiě)
??location?~*?.(gif|jpg|css|png|js|woff|html)(.*){
????#?配置代理轉(zhuǎn)發(fā)規(guī)則
????proxy_pass?http://xmall;
????proxy_set_header?Host?$host;
????proxy_set_header?X-Forwarded-For?$proxy_add_x_forwarded_for;
????proxy_cache?xmall-cache;
????#如果靜態(tài)資源響應(yīng)狀態(tài)碼為200（成功）??302（暫時(shí)性重定向）時(shí)?緩存文件有效期1天
????proxy_cache_valid?200?302?24h;
????#301（永久性重定向）緩存保存5天
????proxy_cache_valid?301?5d;
????#其他情況
????proxy_cache_valid?any?5m;
????#設(shè)置瀏覽器端緩存過(guò)期時(shí)間90天
????expires?90d;
??}

??#使用xmall服務(wù)器池進(jìn)行后端處理

??location?/{
????proxy_pass?http://xmall;?
????proxy_set_header?Host?$host;
????proxy_set_header?X-Forwarded-For?$proxy_add_x_forwarded_for;
??}
}

?

?

增加上面配置后，每一次通過(guò) Nginx 訪問(wèn)應(yīng)用中新的靜態(tài)文件時(shí)，在 Nginx 服務(wù)的緩存目錄便會(huì)生成緩存文件，在緩存有效期內(nèi)該靜態(tài)資源的請(qǐng)求便不再送到后端服務(wù)器，而直接由 Nginx 讀取本地緩存并返回。

服務(wù)層緩存

在前面無(wú)論是 CDN 還是 Nginx，都是對(duì) Web 應(yīng)用中的靜態(tài)資源文件進(jìn)行緩存。但后端應(yīng)用與服務(wù)更多的是訪問(wèn)接口與數(shù)據(jù)，對(duì)于這些對(duì)象我們?nèi)绾卫镁彺婕夹g(shù)進(jìn)行性能優(yōu)化呢？對(duì)于后端應(yīng)用與服務(wù)的緩存可以按部署方式分為進(jìn)程內(nèi)緩存與分布式緩存服務(wù)。

進(jìn)程內(nèi)緩存

所謂進(jìn)程內(nèi)緩存，就是在應(yīng)用中開(kāi)辟的一塊內(nèi)存空間，數(shù)據(jù)在運(yùn)行時(shí)被載入這塊內(nèi)存，通過(guò)本地內(nèi)存的低延遲、高吞吐的特性提高程序的訪問(wèn)速度。進(jìn)程內(nèi)緩存在眾多 Java 框架內(nèi)都有廣泛應(yīng)用，例如 Hibernate、Mybatis 框架的一二級(jí)緩存、Spring MVC 的頁(yè)面緩存都是進(jìn)程內(nèi)緩存的經(jīng)典應(yīng)用場(chǎng)景，這些進(jìn)程內(nèi)緩存在 Java 中也有著非常多優(yōu)秀的開(kāi)源實(shí)現(xiàn)，如 EhCache、Caffeine 都是代表性產(chǎn)品。

分布式緩存服務(wù)

與進(jìn)程內(nèi)相對(duì)的，就是需要獨(dú)立部署的分布式緩存服務(wù)。最常用的是基于 Redis 這種內(nèi)存型 NoSQL 數(shù)據(jù)庫(kù)，對(duì)整體架構(gòu)中的應(yīng)用數(shù)據(jù)進(jìn)行集中緩存。

在架構(gòu)設(shè)計(jì)時(shí)，很多新架構(gòu)師一聽(tīng)到緩存，下意識(shí)認(rèn)為增加 Redis 分布式緩存服務(wù)器就夠了，其實(shí)這是片面的做法。在緩存架構(gòu)設(shè)計(jì)時(shí)，一定要按照由近到遠(yuǎn)、由快到慢的順序進(jìn)行逐級(jí)訪問(wèn)。假設(shè)在電商進(jìn)行商品秒殺活動(dòng)時(shí)，如果沒(méi)有本地緩存，所有商品、訂單、物流的熱點(diǎn)數(shù)據(jù)都保存在 Redis 服務(wù)器中，每完成一筆訂單，都要額外增加若干次網(wǎng)絡(luò)通信，網(wǎng)絡(luò)通信本身就可能由于各種原因存在通信失敗的問(wèn)題。即便是你能保證網(wǎng)絡(luò) 100% 可用，但 Redis 集群承擔(dān)了來(lái)自所有外部應(yīng)用的訪問(wèn)壓力，一旦突發(fā)流量超過(guò) Redis 的負(fù)載上限，整體架構(gòu)便面臨崩潰的風(fēng)險(xiǎn)。

因此在 Java 的應(yīng)用端也要設(shè)計(jì)多級(jí)緩存，我們將進(jìn)程內(nèi)緩存與分布式緩存服務(wù)結(jié)合，有效分?jǐn)倯?yīng)用壓力。在 Java 應(yīng)用層面，只有 EhCache 的緩存不存在時(shí)，再去 Redis 分布式緩存獲取，如果 Redis 也沒(méi)有此數(shù)據(jù)再去數(shù)據(jù)庫(kù)查詢(xún)，數(shù)據(jù)查詢(xún)成功后對(duì) Redis 與 EhCahce 同時(shí)進(jìn)行雙寫(xiě)更新。這樣 Java 應(yīng)用下一次再查詢(xún)相同數(shù)據(jù)時(shí)便直接從本地 EhCache 緩存提取，不再產(chǎn)生新的網(wǎng)絡(luò)通信，應(yīng)用查詢(xún)性能得到顯著提高。

保障緩存一致性

但事無(wú)完美，當(dāng)引入多級(jí)緩存后，我們又會(huì)遇到緩存數(shù)據(jù)一致性的挑戰(zhàn)，以下圖為例：

我們都知道作為數(shù)據(jù)庫(kù)寫(xiě)操作，是不通過(guò)緩存的。假設(shè)商品服務(wù)實(shí)例 1 將 1 號(hào)商品價(jià)格調(diào)整為 80 元，這會(huì)衍生一個(gè)新問(wèn)題：如何主動(dòng)向應(yīng)用程序推送數(shù)據(jù)變更的消息來(lái)保證它們也能同步更新緩存呢？

相信此時(shí)你已經(jīng)有了答案。沒(méi)錯(cuò)，我們需要在當(dāng)前架構(gòu)中引入 MQ 消息隊(duì)列，利用 RocketMQ 的主動(dòng)推送功能來(lái)向其他服務(wù)實(shí)例以及 Redis 緩存服務(wù)發(fā)起變更通知。

如上圖所示，在商品服務(wù)實(shí)例 1 對(duì)商品調(diào)價(jià)后，主動(dòng)向 RocketMQ Broker 發(fā)送變更消息，Broker 將變更信息推送至其他實(shí)例與 Redis 集群，這些服務(wù)實(shí)例在收到變更消息后，在緩存中先刪除過(guò)期緩存，再創(chuàng)建新的數(shù)據(jù)，以此保證各實(shí)例數(shù)據(jù)一致。

看到這里你會(huì)發(fā)現(xiàn)，對(duì)于緩存來(lái)說(shuō)，并沒(méi)有終極的解決方案。雖然多級(jí)緩存設(shè)計(jì)帶來(lái)了更好的應(yīng)用性能，但也為了緩存一致性必須引入 MQ 增加了架構(gòu)的復(fù)雜度。那到底多級(jí)緩存設(shè)計(jì)該如何取舍呢？在我看來(lái)，有三種情況特別適合引入多級(jí)緩存。

第一種情況，緩存的數(shù)據(jù)是穩(wěn)定的。例如郵政編碼、地域區(qū)塊、歸檔的歷史數(shù)據(jù)這些信息適合通過(guò)多級(jí)緩存減小 Redis 與數(shù)據(jù)庫(kù)的壓力。

第二種情況，瞬時(shí)可能會(huì)產(chǎn)生極高并發(fā)的場(chǎng)景。例如春運(yùn)購(gòu)票、雙 11 零點(diǎn)秒殺、股市開(kāi)盤(pán)交易等，瞬間的流量洪峰可能擊穿 Redis 緩存，產(chǎn)生流量雪崩。這時(shí)利用預(yù)熱的進(jìn)程內(nèi)緩存分?jǐn)偭髁?，減少后端壓力是非常有必要的。

第三種情況，一定程度上允許數(shù)據(jù)不一致。例如某博客平臺(tái)中你修改了自我介紹這樣的非關(guān)鍵信息，此時(shí)在應(yīng)用集群中其他節(jié)點(diǎn)緩存不一致也并不會(huì)帶來(lái)嚴(yán)重影響，對(duì)于這種情況我們采用 T+1 的方式在日終處理時(shí)保證緩存最終一致就可以了。

以上是我總結(jié)的三種適合服務(wù)層做多級(jí)緩存的場(chǎng)景。當(dāng)然如果你們的應(yīng)用并發(fā)量不大，在未來(lái)的 1~2 年內(nèi)利用 Redis 分布式緩存集群完全可以勝任應(yīng)用性能要求，那自然就沒(méi)有必要設(shè)計(jì)多級(jí)緩存，我們要根據(jù)業(yè)務(wù)特點(diǎn)靈活調(diào)整架構(gòu)。

小結(jié)

今天咱們介紹了在應(yīng)用微服務(wù)架構(gòu)下從客戶(hù)端到服務(wù)層，各層的緩存設(shè)計(jì)以及解決方案，講解了從瀏覽器的 Expires 響應(yīng)頭到 CDN、Nginx 的靜態(tài)資源緩存，再到服務(wù)層針對(duì)數(shù)據(jù)的多級(jí)緩存，使你對(duì)微服務(wù)架構(gòu)的緩存有了總體的了解。

編輯：黃飛

?