今天我們來聊聊緩存這個話題，看看在微服務環境下如何設計有效的多級緩存架構。主要涉及三方面内容：
- Web 應用的用戶端緩存；
- 應用層靜态資源緩存；
- 服務層多級緩存。
首先，咱們先講解微服務架構的多級緩存設計。
微服務架構中的多級緩存設計
提到緩存，想必每一位軟體工程師都不陌生，它是目前架構設計中提高性能最直接的方式。這裡我們舉個例子：
假設應用程式将原始資料存儲在 MySQL 資料庫中。衆所周知 MySQL 資料庫會将資料存儲在硬碟以防止掉電丢失，但是受制于硬碟的實體設計，即便是目前性能最好的企業級 SSD 硬碟，也比記憶體的這種高速裝置 IO 層面差一個數量級，而以淘寶、京東這種電商為代表的網際網路應用，都是典型的 “讀多寫少” 的場景，是以我們需要在設計上進行資料的讀寫分離，在資料寫入時直接落盤處理，而占比超過 90% 的資料讀取操作時則從以 Redis 為代表的記憶體 NoSQL 資料庫提取資料，利用記憶體的高吞吐瞬間完成資料提取，這裡 Redis 的作用就是我們常說的緩存。
當然，緩存可不隻有用記憶體替代硬碟這一種形式，在分布式架構下緩存在每一層都有自己的設計，下面咱們通過這個微服務的多級緩存架構圖為主線進行講解。
這張圖從上到下包含四層，分别為：用戶端、應用層、服務層以及資料層。
用戶端緩存
X 商城用戶端為浏覽器，在浏覽器層面我們主要是對 HTML 中的圖檔、CSS、JS、字型這些靜态資源進行緩存。
我們以百度 Logo 圖檔為例，百度在 HTTP 通過 Expires 響應頭控制靜态圖檔的有效期。Expires 代表過期時間。目前百度 Logo 的過期時間為 2031 年 2 月 8 日 9 時 26 分 31 秒。在這個時間段内，浏覽器會将圖檔以檔案形式緩存在本地，再次通路時會看到“from disk cache”的提示，此時浏覽器不再産生與伺服器的實際請求，會從本地直接讀取緩存圖檔。通過在浏覽器端設定 Expires 可以在很大程度減少重複請求靜态資源帶來的帶寬損耗，這在高并發 Web 應用中是基礎而重要的設定。
應用層緩存
那 Expires 到底在哪裡進行設定呢？對于浏覽器來說它隻是用戶端，隻負責讀取Expires響應頭，對于 Expires 要在應用層，也就是 CDN 與 Nginx 中進行設定。
CDN 内容分發網絡
CDN 全稱是 Content Delivery Network，即内容分發網絡，是網際網路靜态資源分發的主要技術手段。
CDN 内容分發網絡
中國幅員遼闊，從北京到上海就有上千公裡，如果大量的上海使用者同時要通路千裡之外的北京伺服器的資源，這麼長的通信必然帶來高延遲與更多不可控因素影響資料傳輸，如果有某種機制允許将北京的靜态檔案緩存到上海的伺服器，上海使用者自動就近通路伺服器擷取資源，這樣便可很大程度降低網絡延遲，進而提高系統的可用性。而剛才提到的分布式緩存技術就是我們常提到的CDN（内容分發網絡）。
對于廣域的網際網路應用，CDN 幾乎是必需的基礎設施，它有效解決了帶寬集中占用以及資料分發的問題。像 Web 頁面中的圖檔、音視訊、CSS、JS 這些靜态資源，都可以通過 CDN 伺服器就近擷取。
CDN 技術的核心是“智能 DNS”，智能 DNS 會根據使用者的 IP 位址自動确定就近通路 CDN 節點，咱們以下圖為例：
以某上海使用者的浏覽器要通路商城首頁廣告位的 banner.jpg 檔案，浏覽器通過服務商提供的智能 DNS 服務，将請求自動轉發到商城在上海地區準備的 CDN 伺服器，上海 CDN 收到請求後首先檢查本機是否已緩存過 banner.jpg，如果檔案已存在便直接将圖檔資料傳回給用戶端；如果沒有緩存過，則回源到北京的源資料節點，将 banner.jpg 檔案抽取并緩存到上海伺服器，最後上海 CDN 節點再将本機的 banner.jpg 傳回給用戶端。對于 banner.jpg 來說，第一次通路後上海 CDN 節點已緩存該檔案，則之後的緩存有效期内所有後續通路由上海 CDN 直接提供。與之類似的，商城應用可以在重要城市搭建 CDN 節點，這樣原本集中被發往北京伺服器的請求就被分攤到 CDN 節點，這也直接降低了北京機房的帶寬壓力。
在網際網路應用中，因為 CDN 涉及多地域多節點組網，前期投入成本較高，更多的中小型軟體公司通常會選擇阿裡雲、騰訊雲等大廠提供的 CDN 服務，通過按需付費的方式降低硬體成本。而這些服務商又會為 CDN 賦予額外的能力，比如阿裡雲、騰訊雲 CDN 除了緩存檔案之外，還提供了管理背景能為響應賦予額外的響應頭。如下所示在阿裡雲 CDN 背景，就額外設定了 Cache-Control 響應頭代表緩存有效期為 1 小時。這裡我們額外提一下 Expires 與的 Cache-Control 的差別，Expires 是指定具體某個時間點緩存到期，而 Cache-Control 則代表緩存的有效期是多長時間。Expires 設定時間，Cache-Control 設定時長，根據業務場景不同可以使用不同的響應頭。
Nginx 緩存管理
說完 CDN，下面再來聊一下 Nginx。Nginx 是一款開源的、跨平台的高性能 Web 伺服器，它有着高性能，穩定性好，配置簡單，子產品結構化，資源消耗低的優點。同時支援反向代理、負載均衡、緩存的功能。Nginx 是 Web 應用架構中的常客，例如後端 Tomcat 叢集便可通過增加 Nginx 前置做軟負載均衡，為應用提供高可用特性。
在網際網路應用中，使用者分布在全國各地，對資源的響應速度與帶寬要求較高，是以部署 CDN 是十分有必要的。但在更多的企業應用中，其實大部分的企業使用者都分布在指定的辦公區域或者相對固定的場所，再加上并發使用者相對較少，其實并不需要額外部署 CDN 這種重量級解決方案。在架構中隻需要部署 Nginx 伺服器，利用 Nginx 自帶的靜态資源緩存與壓縮功能便可勝任大多數企業應用場景。
在 Nginx 中自帶将後端應用中圖檔、CSS、JS 等靜态資源緩存功能，我們隻需在 Nginx 的核心配置 nginx.conf 中增加下面的片段，便可對後端的靜态資源進行緩存，關鍵配置我已做好注釋，同學們可以直接使用。
# 設定緩存目錄
# levels代表采用1:2也就是兩級目錄的形式儲存緩存檔案（靜态資源css、js）
# keys_zone定義緩存的名稱及記憶體的使用，名稱為babytun-cache ,在記憶體中開始100m交換空間
# inactive=7d 如果某個緩存檔案超過7天沒有被通路，則删除
# max_size=20g;代表設定檔案夾最大不能超過20g，超過後會自動将通路頻度（命中率）最低的緩存檔案删除
proxy_cache_path d:/nginx-cache levels=1:2 keys_zone=babytun-cache:100m inactive=7d max_size=20g;
#配置xmall後端伺服器的權重負載均衡政策
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通過80端口提供Web服務
listen 80;
# 開啟靜态資源緩存
# 利用正規表達式比對URL，比對成功的則執行内部邏輯
# ~* 代表URL比對不區分大小寫
location ~* \.(gif|jpg|css|png|js|woff|html)(.*){
# 配置代理轉發規則
proxy_pass http://xmall;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache xmall-cache;
#如果靜态資源響應狀态碼為200（成功） 302（暫時性重定向）時 緩存檔案有效期1天
proxy_cache_valid 200 302 24h;
#301（永久性重定向）緩存儲存5天
proxy_cache_valid 301 5d;
#其他情況
proxy_cache_valid any 5m;
#設定浏覽器端緩存過期時間90天
expires 90d;
}
#使用xmall伺服器池進行後端處理
location /{
proxy_pass http://xmall;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
複制代碼 增加上面配置後，每一次通過 Nginx 通路應用中新的靜态檔案時，在 Nginx 服務的緩存目錄便會生成緩存檔案，在緩存有效期内該靜态資源的請求便不再送到後端伺服器，而直接由 Nginx 讀取本地緩存并傳回。
服務層緩存
在前面無論是 CDN 還是 Nginx，都是對 Web 應用中的靜态資源檔案進行緩存。但後端應用與服務更多的是通路接口與資料，對于這些對象我們如何利用緩存技術進行性能優化呢？對于後端應用與服務的緩存可以按部署方式分為程序内緩存與分布式緩存服務。
程序内緩存
所謂程序内緩存，就是在應用中開辟的一塊記憶體空間，資料在運作時被載入這塊記憶體，通過本地記憶體的低延遲、高吞吐的特性提高程式的通路速度。程序内緩存在衆多 Java 架構内都有廣泛應用，例如 Hibernate、Mybatis 架構的一二級緩存、Spring MVC 的頁面緩存都是程序内緩存的經典應用場景，這些程序内緩存在 Java 中也有着非常多優秀的開源實作，如 EhCache、Caffeine 都是代表性産品。
分布式緩存服務
與程序内相對的，就是需要獨立部署的分布式緩存服務。最常用的是基于 Redis 這種記憶體型 NoSQL 資料庫，對整體架構中的應用資料進行集中緩存。
在架構設計時，很多新架構師一聽到緩存，下意識認為增加 Redis 分布式緩存伺服器就夠了，其實這是片面的做法。在緩存架構設計時，一定要按照由近到遠、由快到慢的順序進行逐級通路。假設在電商進行商品秒殺活動時，如果沒有本地緩存，所有商品、訂單、物流的熱點資料都儲存在 Redis 伺服器中，每完成一筆訂單，都要額外增加若幹次網絡通信，網絡通信本身就可能由于各種原因存在通信失敗的問題。即便是你能保證網絡 100% 可用，但 Redis 叢集承擔了來自所有外部應用的通路壓力，一旦突發流量超過 Redis 的負載上限，整體架構便面臨崩潰的風險。
是以在 Java 的應用端也要設計多級緩存，我們将程序内緩存與分布式緩存服務結合，有效分攤應用壓力。在 Java 應用層面，隻有 EhCache 的緩存不存在時，再去 Redis 分布式緩存擷取，如果 Redis 也沒有此資料再去資料庫查詢，資料查詢成功後對 Redis 與 EhCahce 同時進行雙寫更新。這樣 Java 應用下一次再查詢相同資料時便直接從本地 EhCache 緩存提取，不再産生新的網絡通信，應用查詢性能得到顯著提高。
保障緩存一緻性
但事無完美，當引入多級緩存後，我們又會遇到緩存資料一緻性的挑戰，以下圖為例：
我們都知道作為資料庫寫操作，是不通過緩存的。假設商品服務執行個體 1 将 1 号商品價格調整為 80 元，這會衍生一個新問題：如何主動向應用程式推送資料變更的消息來保證它們也能同步更新緩存呢？
相信此時你已經有了答案。沒錯，我們需要在目前架構中引入 MQ 消息隊列，利用 RocketMQ 的主動推送功能來向其他服務執行個體以及 Redis 緩存服務發起變更通知。
如上圖所示，在商品服務執行個體 1 對商品調價後，主動向 RocketMQ Broker 發送變更消息，Broker 将變更資訊推送至其他執行個體與 Redis 叢集，這些服務執行個體在收到變更消息後，在緩存中先删除過期緩存，再建立新的資料，以此保證各執行個體資料一緻。
看到這裡你會發現，對于緩存來說，并沒有終極的解決方案。雖然多級緩存設計帶來了更好的應用性能，但也為了緩存一緻性必須引入 MQ 增加了架構的複雜度。那到底多級緩存設計該如何取舍呢？在我看來，有三種情況特别适合引入多級緩存。
第一種情況，緩存的資料是穩定的。例如郵政編碼、地域區塊、歸檔的曆史資料這些資訊适合通過多級緩存減小 Redis 與資料庫的壓力。
第二種情況，瞬時可能會産生極高并發的場景。例如春運購票、雙 11 零點秒殺、股市開盤交易等，瞬間的流量洪峰可能擊穿 Redis 緩存，産生流量雪崩。這時利用預熱的程序内緩存分攤流量，減少後端壓力是非常有必要的。
第三種情況，一定程度上允許資料不一緻。例如某部落格平台中你修改了自我介紹這樣的非關鍵資訊，此時在應用叢集中其他節點緩存不一緻也并不會帶來嚴重影響，對于這種情況我們采用T+1的方式在日終處理時保證緩存最終一緻就可以了。
以上是我總結的三種适合服務層做多級緩存的場景。當然如果你們的應用并發量不大，在未來的1~2 年内利用 Redis 分布式緩存叢集完全可以勝任應用性能要求，那自然就沒有必要設計多級緩存，我們要根據業務特點靈活調整架構。
小結
今天咱們介紹了在應用微服務架構下從用戶端到服務層，各層的緩存設計以及解決方案，講解了從浏覽器的 Expires 響應頭到 CDN、Nginx 的靜态資源緩存，再到服務層針對資料的多級緩存，使你對微服務架構的緩存有了總體的了解。
原文連結：https://juejin.cn/post/7202479313228218428