作者｜vivo互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)-Zhang Peng

一、緩存簡(jiǎn)介

1.1 什么是緩存

緩存就是數(shù)據(jù)交換的緩沖區(qū)。緩存的本質(zhì)是一個(gè)內(nèi)存 Hash。緩存是一種利用空間換時(shí)間的設(shè)計(jì)，其目標(biāo)就是更快、更近：極大的提高。

• 將數(shù)據(jù)寫入/讀取速度更快的存儲(chǔ)(設(shè)備);
• 將數(shù)據(jù)緩存到離應(yīng)用最近的位置;
• 將數(shù)據(jù)緩存到離用戶最近的位置。

緩存是用于存儲(chǔ)數(shù)據(jù)的硬件或軟件的組成部分，以使得后續(xù)更快訪問相應(yīng)的數(shù)據(jù)。緩存中的數(shù)據(jù)可能是提前計(jì)算好的結(jié)果、數(shù)據(jù)的副本等。典型的應(yīng)用場(chǎng)景：有 cpu cache, 磁盤 cache 等。本文中提及到緩存主要是指互聯(lián)網(wǎng)應(yīng)用中所使用的緩存組件。

緩存命中率是緩存的重要度量指標(biāo)，命中率越高越好。

緩存命中率 = 從緩存中讀取次數(shù) / 總讀取次數(shù)

1.2 何時(shí)需要緩存

引入緩存，會(huì)增加系統(tǒng)的復(fù)雜度。所以，引入緩存前，需要先權(quán)衡是否值得，考量點(diǎn)如下：

• CPU 開銷 - 如果應(yīng)用某個(gè)計(jì)算需要消耗大量 CPU，可以考慮緩存其計(jì)算結(jié)果。典型場(chǎng)景：復(fù)雜的、頻繁調(diào)用的正則計(jì)算;分布式計(jì)算中間狀態(tài)等。
• IO 開銷 - 如果數(shù)據(jù)庫(kù)連接池比較繁忙，可以考慮緩存其查詢結(jié)果。

在數(shù)據(jù)層引入緩存，有以下幾個(gè)好處：

• 提升數(shù)據(jù)讀取速度。
• 提升系統(tǒng)擴(kuò)展能力，通過擴(kuò)展緩存，提升系統(tǒng)承載能力。
• 降低存儲(chǔ)成本，Cache+DB 的方式可以承擔(dān)原有需要多臺(tái) DB 才能承擔(dān)的請(qǐng)求量，節(jié)省機(jī)器成本。

1.3 緩存的基本原理

根據(jù)業(yè)務(wù)場(chǎng)景，通常緩存有以下幾種使用方式：

懶漢式(讀時(shí)觸發(fā))：先查詢 DB 里的數(shù)據(jù), 然后把相關(guān)的數(shù)據(jù)寫入 Cache。

饑餓式(寫時(shí)觸發(fā))：寫入 DB 后, 然后把相關(guān)的數(shù)據(jù)也寫入 Cache。

定期刷新：適合周期性的跑數(shù)據(jù)的任務(wù)，或者列表型的數(shù)據(jù)，而且不要求絕對(duì)實(shí)時(shí)性。

1.4 緩存淘汰策略

緩存淘汰的類型：

1)基于空間：設(shè)置緩存空間大小。

2)基于容量：設(shè)置緩存存儲(chǔ)記錄數(shù)。

3)基于時(shí)間

• TTL(Time To Live，即存活期)緩存數(shù)據(jù)從創(chuàng)建到過期的時(shí)間。
• TTI(Time To Idle，即空閑期)緩存數(shù)據(jù)多久沒被訪問的時(shí)間。

緩存淘汰算法：

1)FIFO：先進(jìn)先出。在這種淘汰算法中，先進(jìn)入緩存的會(huì)先被淘汰。這種可謂是最簡(jiǎn)單的了，但是會(huì)導(dǎo)致我們命中率很低。試想一下我們?nèi)绻袀€(gè)訪問頻率很高的數(shù)據(jù)是所有數(shù)據(jù)第一個(gè)訪問的，而那些不是很高的是后面再訪問的，那這樣就會(huì)把我們的首個(gè)數(shù)據(jù)但是他的訪問頻率很高給擠出。

2)LRU：最近最少使用算法。在這種算法中避免了上面的問題，每次訪問數(shù)據(jù)都會(huì)將其放在我們的隊(duì)尾，如果需要淘汰數(shù)據(jù)，就只需要淘汰隊(duì)首即可。但是這個(gè)依然有個(gè)問題，如果有個(gè)數(shù)據(jù)在 1 個(gè)小時(shí)的前 59 分鐘訪問了 1 萬次(可見這是個(gè)熱點(diǎn)數(shù)據(jù)),再后一分鐘沒有訪問這個(gè)數(shù)據(jù)，但是有其他的數(shù)據(jù)訪問，就導(dǎo)致了我們這個(gè)熱點(diǎn)數(shù)據(jù)被淘汰。

3)LFU：最近最少頻率使用。在這種算法中又對(duì)上面進(jìn)行了優(yōu)化，利用額外的空間記錄每個(gè)數(shù)據(jù)的使用頻率，然后選出頻率最低進(jìn)行淘汰。這樣就避免了 LRU 不能處理時(shí)間段的問題。

這三種緩存淘汰算法，實(shí)現(xiàn)復(fù)雜度一個(gè)比一個(gè)高，同樣的命中率也是一個(gè)比一個(gè)好。而我們一般來說選擇的方案居中即可，即實(shí)現(xiàn)成本不是太高，而命中率也還行的 LRU。

二、緩存的分類

緩存從部署角度，可以分為客戶端緩存和服務(wù)端緩存。

客戶端緩存

• HTTP 緩存
• 瀏覽器緩存
• APP 緩存(1、Android 2、IOS)

服務(wù)端緩存

• CDN 緩存：存放 HTML、CSS、JS 等靜態(tài)資源。
• 反向代理緩存：動(dòng)靜分離，只緩存用戶請(qǐng)求的靜態(tài)資源。
• 數(shù)據(jù)庫(kù)緩存：數(shù)據(jù)庫(kù)(如 MySQL)自身一般也有緩存，但因?yàn)槊新屎透骂l率問題，不推薦使用。
• 進(jìn)程內(nèi)緩存：緩存應(yīng)用字典等常用數(shù)據(jù)。
• 分布式緩存：緩存數(shù)據(jù)庫(kù)中的熱點(diǎn)數(shù)據(jù)。

其中，CDN 緩存、反向代理緩存、數(shù)據(jù)庫(kù)緩存一般由專職人員維護(hù)(運(yùn)維、DBA)。后端開發(fā)一般聚焦于進(jìn)程內(nèi)緩存、分布式緩存。

2.1 HTTP 緩存

2.2 CDN 緩存

CDN 將數(shù)據(jù)緩存到離用戶物理距離最近的服務(wù)器，使得用戶可以就近獲取請(qǐng)求內(nèi)容。CDN 一般緩存靜態(tài)資源文件(頁面，腳本，圖片，視頻，文件等)。

國(guó)內(nèi)網(wǎng)絡(luò)異常復(fù)雜，跨運(yùn)營(yíng)商的網(wǎng)絡(luò)訪問會(huì)很慢。為了解決跨運(yùn)營(yíng)商或各地用戶訪問問題，可以在重要的城市，部署 CDN 應(yīng)用。使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問響應(yīng)速度和命中率。

圖片引用自：Why use a CDN

2.1.1 CDN 原理

CDN 的基本原理是廣泛采用各種緩存服務(wù)器，將這些緩存服務(wù)器分布到用戶訪問相對(duì)集中的地區(qū)或網(wǎng)絡(luò)中，在用戶訪問網(wǎng)站時(shí)，利用全局負(fù)載技術(shù)將用戶的訪問指向距離最近的工作正常的緩存服務(wù)器上，由緩存服務(wù)器直接響應(yīng)用戶請(qǐng)求。

1)未部署 CDN 應(yīng)用前的網(wǎng)絡(luò)路徑：

• 請(qǐng)求：本機(jī)網(wǎng)絡(luò)(局域網(wǎng))=> 運(yùn)營(yíng)商網(wǎng)絡(luò) => 應(yīng)用服務(wù)器機(jī)房
• 響應(yīng)：應(yīng)用服務(wù)器機(jī)房 => 運(yùn)營(yíng)商網(wǎng)絡(luò) => 本機(jī)網(wǎng)絡(luò)(局域網(wǎng))

在不考慮復(fù)雜網(wǎng)絡(luò)的情況下，從請(qǐng)求到響應(yīng)需要經(jīng)過 3 個(gè)節(jié)點(diǎn)，6 個(gè)步驟完成一次用戶訪問操作。

2)部署 CDN 應(yīng)用后網(wǎng)絡(luò)路徑：

• 請(qǐng)求：本機(jī)網(wǎng)絡(luò)(局域網(wǎng)) => 運(yùn)營(yíng)商網(wǎng)絡(luò)
• 響應(yīng)：運(yùn)營(yíng)商網(wǎng)絡(luò) => 本機(jī)網(wǎng)絡(luò)(局域網(wǎng))

在不考慮復(fù)雜網(wǎng)絡(luò)的情況下，從請(qǐng)求到響應(yīng)需要經(jīng)過 2 個(gè)節(jié)點(diǎn)，2 個(gè)步驟完成一次用戶訪問操作。與不部署 CDN 服務(wù)相比，減少了 1 個(gè)節(jié)點(diǎn)，4 個(gè)步驟的訪問。極大的提高了系統(tǒng)的響應(yīng)速度。

2.1.2 CDN 特點(diǎn)

優(yōu)點(diǎn)

本地 Cache 加速：提升訪問速度，尤其含有大量圖片和靜態(tài)頁面站點(diǎn);

實(shí)現(xiàn)跨運(yùn)營(yíng)商的網(wǎng)絡(luò)加速：消除了不同運(yùn)營(yíng)商之間互聯(lián)的瓶頸造成的影響，實(shí)現(xiàn)了跨運(yùn)營(yíng)商的網(wǎng)絡(luò)加速，保證不同網(wǎng)絡(luò)中的用戶都能得到良好的訪問質(zhì)量;

遠(yuǎn)程加速：遠(yuǎn)程訪問用戶根據(jù) DNS 負(fù)載均衡技術(shù)智能自動(dòng)選擇 Cache 服務(wù)器，選擇最快的 Cache 服務(wù)器，加快遠(yuǎn)程訪問的速度;

帶寬優(yōu)化：自動(dòng)生成服務(wù)器的遠(yuǎn)程 Mirror(鏡像)cache 服務(wù)器，遠(yuǎn)程用戶訪問時(shí)從 cache 服務(wù)器上讀取數(shù)據(jù)，減少遠(yuǎn)程訪問的帶寬、分擔(dān)網(wǎng)絡(luò)流量、減輕原站點(diǎn) WEB 服務(wù)器負(fù)載等功能。

集群抗攻擊：廣泛分布的 CDN 節(jié)點(diǎn)加上節(jié)點(diǎn)之間的智能冗余機(jī)制，可以有效地預(yù)防黑客入侵以及降低各種 D.D.o.S 攻擊對(duì)網(wǎng)站的影響，同時(shí)保證較好的服務(wù)質(zhì)量。

缺點(diǎn)

不適宜緩存動(dòng)態(tài)資源

解決方案：主要緩存靜態(tài)資源，動(dòng)態(tài)資源建立多級(jí)緩存或準(zhǔn)實(shí)時(shí)同步;

存在數(shù)據(jù)的一致性問題

• 解決方案(主要是在性能和數(shù)據(jù)一致性二者間尋找一個(gè)平衡)。
• 設(shè)置緩存失效時(shí)間(1 個(gè)小時(shí)，過期后同步數(shù)據(jù))。
• 針對(duì)資源設(shè)置版本號(hào)。

2.2 反向代理緩存

反向代理(Reverse Proxy)方式是指以代理服務(wù)器來接受 internet 上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 internet 上請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)反向代理服務(wù)器。

2.2.1 反向代理緩存原理

反向代理位于應(yīng)用服務(wù)器同一網(wǎng)絡(luò)，處理所有對(duì) WEB 服務(wù)器的請(qǐng)求。反向代理緩存的原理：

• 如果用戶請(qǐng)求的頁面在代理服務(wù)器上有緩存的話，代理服務(wù)器直接將緩存內(nèi)容發(fā)送給用戶。
• 如果沒有緩存則先向 WEB 服務(wù)器發(fā)出請(qǐng)求，取回?cái)?shù)據(jù)，本地緩存后再發(fā)送給用戶。

這種方式通過降低向 WEB 服務(wù)器的請(qǐng)求數(shù)，從而降低了 WEB 服務(wù)器的負(fù)載。

反向代理緩存一般針對(duì)的是靜態(tài)資源，而將動(dòng)態(tài)資源請(qǐng)求轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器處理。常用的緩存應(yīng)用服務(wù)器有 Varnish，Ngnix，Squid。

2.2.2 反向代理緩存比較

常用的代理緩存有 Varnish，Squid，Ngnix，簡(jiǎn)單比較如下：

• Varnish 和 Squid 是專業(yè)的 cache 服務(wù)，Ngnix 需要第三方模塊支持;
• Varnish 采用內(nèi)存型緩存，避免了頻繁在內(nèi)存、磁盤中交換文件，性能比 Squid 高;
• Varnish 由于是內(nèi)存 cache，所以對(duì)小文件如 css、js、小圖片的支持很棒，后端的持久化緩存可以采用的是 Squid 或 ATS;
• Squid 功能全而大，適合于各種靜態(tài)的文件緩存，一般會(huì)在前端掛一個(gè) HAProxy 或 Ngnix 做負(fù)載均衡跑多個(gè)實(shí)例;
• Nginx 采用第三方模塊 ncache 做的緩沖，性能基本達(dá)到 Varnish，一般作為反向代理使用，可以實(shí)現(xiàn)簡(jiǎn)單的緩存。

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

進(jìn)程內(nèi)緩存是指應(yīng)用內(nèi)部的緩存，標(biāo)準(zhǔn)的分布式系統(tǒng)，一般有多級(jí)緩存構(gòu)成。本地緩存是離應(yīng)用最近的緩存，一般可以將數(shù)據(jù)緩存到硬盤或內(nèi)存。

硬盤緩存：將數(shù)據(jù)緩存到硬盤中，讀取時(shí)從硬盤讀取。原理是直接讀取本機(jī)文件，減少了網(wǎng)絡(luò)傳輸消耗，比通過網(wǎng)絡(luò)讀取數(shù)據(jù)庫(kù)速度更快?？梢詰?yīng)用在對(duì)速度要求不是很高，但需要大量緩存存儲(chǔ)的場(chǎng)景。

內(nèi)存緩存：直接將數(shù)據(jù)存儲(chǔ)到本機(jī)內(nèi)存中，通過程序直接維護(hù)緩存對(duì)象，是訪問速度最快的方式。

常見的本地緩存實(shí)現(xiàn)方案：HashMap、Guava Cache、Caffeine、Ehcache。

3.1 ConcurrentHashMap

最簡(jiǎn)單的進(jìn)程內(nèi)緩存可以通過 JDK 自帶的 HashMap 或 ConcurrentHashMap 實(shí)現(xiàn)。

適用場(chǎng)景：不需要淘汰的緩存數(shù)據(jù)。

缺點(diǎn)：無法進(jìn)行緩存淘汰，內(nèi)存會(huì)無限制的增長(zhǎng)。

3.2 LRUHashMap

可以通過繼承 LinkedHashMap 來實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 LRUHashMap。重寫 removeEldestEntry 方法，即可完成一個(gè)簡(jiǎn)單的最近最少使用算法。

缺點(diǎn)：

• 鎖競(jìng)爭(zhēng)嚴(yán)重，性能比較低。
• 不支持過期時(shí)間。
• 不支持自動(dòng)刷新。

3.3 Guava Cache

解決了LRUHashMap 中的幾個(gè)缺點(diǎn)。Guava Cache 采用了類似 ConcurrentHashMap 的思想，分段加鎖，減少鎖競(jìng)爭(zhēng)。

Guava Cache 對(duì)于過期的 Entry 并沒有馬上過期(也就是并沒有后臺(tái)線程一直在掃)，而是通過進(jìn)行讀寫操作的時(shí)候進(jìn)行過期處理，這樣做的好處是避免后臺(tái)線程掃描的時(shí)候進(jìn)行全局加鎖。直接通過查詢，判斷其是否滿足刷新條件，進(jìn)行刷新。

3.4 Caffeine

Caffeine 實(shí)現(xiàn)了 W-TinyLFU(LFU + LRU 算法的變種)，其命中率和讀寫吞吐量大大優(yōu)于 Guava Cache。其實(shí)現(xiàn)原理較復(fù)雜，可以參考你應(yīng)該知道的緩存進(jìn)化史。

3.5 Ehcache

EhCache 是一個(gè)純 Java 的進(jìn)程內(nèi)緩存框架，具有快速、精干等特點(diǎn)，是 Hibernate 中默認(rèn)的 CacheProvider。

優(yōu)點(diǎn)

• 快速、簡(jiǎn)單;
• 支持多種緩存策略：LRU、LFU、FIFO 淘汰算法;
• 緩存數(shù)據(jù)有兩級(jí)：內(nèi)存和磁盤，因此無需擔(dān)心容量問題;
• 緩存數(shù)據(jù)會(huì)在虛擬機(jī)重啟的過程中寫入磁盤;
• 可以通過 RMI、可插入 API 等方式進(jìn)行分布式緩存;
• 具有緩存和緩存管理器的偵聽接口;
• 支持多緩存管理器實(shí)例，以及一個(gè)實(shí)例的多個(gè)緩存區(qū)域;
• 提供 Hibernate 的緩存實(shí)現(xiàn)。

缺點(diǎn)

• 使用磁盤 Cache 的時(shí)候非常占用磁盤空間;
• 不保證數(shù)據(jù)的安全;
• 雖然支持分布式緩存，但效率不高(通過組播方式，在不同節(jié)點(diǎn)之間同步數(shù)據(jù))。

3.6 進(jìn)程內(nèi)緩存對(duì)比

常用進(jìn)程內(nèi)緩存技術(shù)對(duì)比：

• ConcurrentHashMap：比較適合緩存比較固定不變的元素，且緩存的數(shù)量較小的。雖然從上面表格中比起來有點(diǎn)遜色，但是其由于是 JDK 自帶的類，在各種框架中依然有大量的使用，比如我們可以用來緩存我們反射的 Method，F(xiàn)ield 等等;也可以緩存一些鏈接，防止其重復(fù)建立。在 Caffeine 中也是使用的 ConcurrentHashMap 來存儲(chǔ)元素。
• LRUMap：如果不想引入第三方包，又想使用淘汰算法淘汰數(shù)據(jù)，可以使用這個(gè)。
• Ehcache：由于其 jar 包很大，較重量級(jí)。對(duì)于需要持久化和集群的一些功能的，可以選擇 Ehcache。需要注意的是，雖然 Ehcache 也支持分布式緩存，但是由于其節(jié)點(diǎn)間通信方式為 rmi，表現(xiàn)不如 Redis，所以一般不建議用它來作為分布式緩存。
• Guava Cache：Guava 這個(gè) jar 包在很多 Java 應(yīng)用程序中都有大量的引入，所以很多時(shí)候其實(shí)是直接用就好了，并且其本身是輕量級(jí)的而且功能較為豐富，在不了解 Caffeine 的情況下可以選擇 Guava Cache。
• Caffeine：其在命中率，讀寫性能上都比 Guava Cache 好很多，并且其 API 和 Guava cache 基本一致，甚至?xí)嘁稽c(diǎn)。在真實(shí)環(huán)境中使用 Caffeine，取得過不錯(cuò)的效果。

總結(jié)一下：如果不需要淘汰算法則選擇 ConcurrentHashMap，如果需要淘汰算法和一些豐富的 API，推薦選擇。

四、分布式緩存

分布式緩存解決了進(jìn)程內(nèi)緩存最大的問題：如果應(yīng)用是分布式系統(tǒng)，節(jié)點(diǎn)之間無法共享彼此的進(jìn)程內(nèi)緩存。分布式緩存的應(yīng)用場(chǎng)景：

• 緩存經(jīng)過復(fù)雜計(jì)算得到的數(shù)據(jù)。
• 緩存系統(tǒng)中頻繁訪問的熱點(diǎn)數(shù)據(jù)，減輕數(shù)據(jù)庫(kù)壓力。

不同分布式緩存的實(shí)現(xiàn)原理往往有比較大的差異。本文主要針對(duì) Memcached 和 Redis 進(jìn)行說明。

4.1 Memcached

Memcached 是一個(gè)高性能，分布式內(nèi)存對(duì)象緩存系統(tǒng)，通過在內(nèi)存里維護(hù)一個(gè)統(tǒng)一的巨大的 Hash 表，它能夠用來存儲(chǔ)各種格式的數(shù)據(jù)，包括圖像、視頻、文件以及數(shù)據(jù)庫(kù)檢索的結(jié)果等。

簡(jiǎn)單的說就是：將數(shù)據(jù)緩存到內(nèi)存中，然后從內(nèi)存中讀取，從而大大提高讀取速度。

4.1.1 Memcached 特性

使用物理內(nèi)存作為緩存區(qū)，可獨(dú)立運(yùn)行在服務(wù)器上。每個(gè)進(jìn)程最大 2G，如果想緩存更多的數(shù)據(jù)，可以開辟更多的 Memcached 進(jìn)程(不同端口)或者使用分布式 Memcached 進(jìn)行緩存，將數(shù)據(jù)緩存到不同的物理機(jī)或者虛擬機(jī)上。

使用 key-value 的方式來存儲(chǔ)數(shù)據(jù)。這是一種單索引的結(jié)構(gòu)化數(shù)據(jù)組織形式，可使數(shù)據(jù)項(xiàng)查詢時(shí)間復(fù)雜度為 O(1)。

協(xié)議簡(jiǎn)單，基于文本行的協(xié)議。直接通過 telnet 在 Memcached 服務(wù)器上可進(jìn)行存取數(shù)據(jù)操作，簡(jiǎn)單，方便多種緩存參考此協(xié)議;

基于 libevent 高性能通信。Libevent 是一套利用 C 開發(fā)的程序庫(kù)，它將 BSD 系統(tǒng)的 kqueue,Linux 系統(tǒng)的 epoll 等事件處理功能封裝成一個(gè)接口，與傳統(tǒng)的 select 相比，提高了性能。

分布式能力取決于 Memcached 客戶端，服務(wù)器之間互不通信。各個(gè) Memcached 服務(wù)器之間互不通信，各自獨(dú)立存取數(shù)據(jù)，不共享任何信息。服務(wù)器并不具有分布式功能，分布式部署取決于 Memcached 客戶端。

采用 LRU 緩存淘汰策略。在 Memcached 內(nèi)存儲(chǔ)數(shù)據(jù)項(xiàng)時(shí)，可以指定它在緩存的失效時(shí)間，默認(rèn)為永久。當(dāng) Memcached 服務(wù)器用完分配的內(nèi)時(shí)，失效的數(shù)據(jù)被首先替換，然后也是最近未使用的數(shù)據(jù)。在 LRU 中，Memcached 使用的是一種 Lazy Expiration 策略，自己不會(huì)監(jiān)控存入的 key/vlue 對(duì)是否過期，而是在獲取 key 值時(shí)查看記錄的時(shí)間戳，檢查 key/value 對(duì)空間是否過期，這樣可減輕服務(wù)器的負(fù)載。

內(nèi)置了一套高效的內(nèi)存管理算法。這套內(nèi)存管理效率很高，而且不會(huì)造成內(nèi)存碎片，但是它最大的缺點(diǎn)就是會(huì)導(dǎo)致空間浪費(fèi)。當(dāng)內(nèi)存滿后，通過 LRU 算法自動(dòng)刪除不使用的緩存。

不支持持久化。Memcached 沒有考慮數(shù)據(jù)的容災(zāi)問題，重啟服務(wù)，所有數(shù)據(jù)會(huì)丟失。

4.1.2 Memcached 工作原理

1)內(nèi)存管理

Memcached 利用 slab allocation 機(jī)制來分配和管理內(nèi)存，它按照預(yù)先規(guī)定的大小，將分配的內(nèi)存分割成特定長(zhǎng)度的內(nèi)存塊，再把尺寸相同的內(nèi)存塊分成組，數(shù)據(jù)在存放時(shí)，根據(jù)鍵值 大小去匹配 slab 大小，找就近的 slab 存放，所以存在空間浪費(fèi)現(xiàn)象。

這套內(nèi)存管理效率很高，而且不會(huì)造成內(nèi)存碎片，但是它最大的缺點(diǎn)就是會(huì)導(dǎo)致空間浪費(fèi)。

2)緩存淘汰策略

Memcached 的緩存淘汰策略是 LRU + 到期失效策略。

當(dāng)你在 Memcached 內(nèi)存儲(chǔ)數(shù)據(jù)項(xiàng)時(shí)，你有可能會(huì)指定它在緩存的失效時(shí)間，默認(rèn)為永久。當(dāng) Memcached 服務(wù)器用完分配的內(nèi)時(shí)，失效的數(shù)據(jù)被首先替換，然后是最近未使用的數(shù)據(jù)。

在 LRU 中，Memcached 使用的是一種 Lazy Expiration 策略：Memcached 不會(huì)監(jiān)控存入的 key/vlue 對(duì)是否過期，而是在獲取 key 值時(shí)查看記錄的時(shí)間戳，檢查 key/value 對(duì)空間是否過期，這樣可減輕服務(wù)器的負(fù)載。

3)分區(qū)

Memcached 服務(wù)器之間彼此不通信，它的分布式能力是依賴客戶端來實(shí)現(xiàn)。具體來說，就是在客戶端實(shí)現(xiàn)一種算法，根據(jù) key 來計(jì)算出數(shù)據(jù)應(yīng)該向哪個(gè)服務(wù)器節(jié)點(diǎn)讀/寫。

而這種選取集群節(jié)點(diǎn)的算法常見的有三種：

哈希取余算法：使用公式：Hash(key)% N 計(jì)算出 哈希值 來決定數(shù)據(jù)映射到哪一個(gè)節(jié)點(diǎn)。

一致性哈希算法：可以很好的解決 穩(wěn)定性問題，可以將所有的 存儲(chǔ)節(jié)點(diǎn) 排列在 首尾相接 的 Hash 環(huán)上，每個(gè) key 在計(jì)算 Hash 后會(huì) 順時(shí)針 找到 臨接 的 存儲(chǔ)節(jié)點(diǎn) 存放。而當(dāng)有節(jié)點(diǎn) 加入 或 退出 時(shí)，僅影響該節(jié)點(diǎn)在 Hash 環(huán)上 順時(shí)針相鄰 的 后續(xù)節(jié)點(diǎn)。

虛擬 Hash 槽算法：使用 分散度良好 的 哈希函數(shù) 把所有數(shù)據(jù) 映射 到一個(gè) 固定范圍 的 整數(shù)集合 中，整數(shù)定義為 槽(slot)，這個(gè)范圍一般 遠(yuǎn)遠(yuǎn)大于 節(jié)點(diǎn)數(shù)。槽 是集群內(nèi) 數(shù)據(jù)管理 和 遷移 的 基本單位。采用 大范圍槽 的主要目的是為了方便 數(shù)據(jù)拆分 和 集群擴(kuò)展。每個(gè)節(jié)點(diǎn)會(huì)負(fù)責(zé) 一定數(shù)量的槽。

4.2 Redis

Redis 是一個(gè)開源(BSD 許可)的，基于內(nèi)存的，多數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)系統(tǒng)。可以用作數(shù)據(jù)庫(kù)、緩存和消息中間件。

Redis 還可以使用客戶端分片來擴(kuò)展寫性能。內(nèi)置了 復(fù)制(replication)，LUA 腳本(Lua scripting)，LRU 驅(qū)動(dòng)事件(LRU eviction)，事務(wù)(transactions) 和不同級(jí)別的 磁盤持久化(persistence)， 并通過 Redis 哨兵(Sentinel)和自動(dòng)分區(qū)(Cluster)提供高可用性(high availability)。

4.2.1 Redis 特性

支持多種數(shù)據(jù)類型 - string、Hash、list、set、sorted set。

支持多種數(shù)據(jù)淘汰策略;

volatile-lru：從已設(shè)置過期時(shí)間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰;

volatile-ttl ：從已設(shè)置過期時(shí)間的數(shù)據(jù)集中挑選將要過期的數(shù)據(jù)淘汰;

volatile-random：從已設(shè)置過期時(shí)間的數(shù)據(jù)集中任意選擇數(shù)據(jù)淘汰;

allkeys-lru：從所有數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰;

allkeys-random：從所有數(shù)據(jù)集中任意選擇數(shù)據(jù)進(jìn)行淘汰;

noeviction ：禁止驅(qū)逐數(shù)據(jù)。

• 提供兩種持久化方式 - RDB 和 AOF。
• 通過 Redis cluster 提供集群模式。

4.2.2 Redis 原理

1)緩存淘汰

Redis 有兩種數(shù)據(jù)淘汰實(shí)現(xiàn);

• 消極方式：訪問 Redis key 時(shí)，如果發(fā)現(xiàn)它已經(jīng)失效，則刪除它
• 積極方式：周期性從設(shè)置了失效時(shí)間的 key 中，根據(jù)淘汰策略，選擇一部分失效的 key 進(jìn)行刪除。

2)分區(qū)

Redis Cluster 集群包含 16384 個(gè)虛擬 Hash 槽，它通過一個(gè)高效的算法來計(jì)算 key 屬于哪個(gè) Hash 槽。

Redis Cluster 支持請(qǐng)求分發(fā) - 節(jié)點(diǎn)在接到一個(gè)命令請(qǐng)求時(shí)，會(huì)先檢測(cè)這個(gè)命令請(qǐng)求要處理的鍵所在的槽是否由自己負(fù)責(zé)，如果不是的話，節(jié)點(diǎn)將向客戶端返回一個(gè) MOVED 錯(cuò)誤，MOVED 錯(cuò)誤攜帶的信息可以指引客戶端將請(qǐng)求重定向至正在負(fù)責(zé)相關(guān)槽的節(jié)點(diǎn)。

3)主從復(fù)制

Redis 2.8 后支持異步復(fù)制。它有兩種模式：

• 完整重同步(full resychronization) - 用于初次復(fù)制。執(zhí)行步驟與 SYNC 命令基本一致。
• 部分重同步(partial resychronization) - 用于斷線后重復(fù)制。如果條件允許，主服務(wù)器可以將主從服務(wù)器連接斷開期間執(zhí)行的寫命令發(fā)送給從服務(wù)器，從服務(wù)器只需接收并執(zhí)行這些寫命令，即可將主從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)保持一致。

集群中每個(gè)節(jié)點(diǎn)都會(huì)定期向集群中的其他節(jié)點(diǎn)發(fā)送 PING 消息，以此來檢測(cè)對(duì)方是否在線。

如果一個(gè)主節(jié)點(diǎn)被認(rèn)為下線，則在其從節(jié)點(diǎn)中，根據(jù) Raft 算法，選舉出一個(gè)節(jié)點(diǎn)，升級(jí)為主節(jié)點(diǎn)。

4)數(shù)據(jù)一致性

Redis 不保證強(qiáng)一致性，因?yàn)檫@會(huì)使得集群性能大大降低。

Redis 是通過異步復(fù)制來實(shí)現(xiàn)最終一致性。

4.3 分布式緩存對(duì)比

不同的分布式緩存功能特性和實(shí)現(xiàn)原理方面有很大的差異，因此他們所適應(yīng)的場(chǎng)景也有所不同。

這里選取三個(gè)比較出名的分布式緩存(MemCache，Redis，Tair)來作為比較：

• MemCache：只適合基于內(nèi)存的緩存框架;且不支持?jǐn)?shù)據(jù)持久化和容災(zāi)。
• Redis：支持豐富的數(shù)據(jù)結(jié)構(gòu)，讀寫性能很高，但是數(shù)據(jù)全內(nèi)存，必須要考慮資源成本，支持持久化。
• Tair：支持豐富的數(shù)據(jù)結(jié)構(gòu)，讀寫性能較高，部分類型比較慢，理論上容量可以無限擴(kuò)充。

總結(jié)：如果服務(wù)對(duì)延遲比較敏感，Map/Set 數(shù)據(jù)也比較多的話，比較適合 Redis。如果服務(wù)需要放入緩存量的數(shù)據(jù)很大，對(duì)延遲又不是特別敏感的話，那就可以選擇 Memcached。

五、多級(jí)緩存

5.1 整體緩存框架

通常，一個(gè)大型軟件系統(tǒng)的緩存采用多級(jí)緩存方案：

請(qǐng)求過程：

• 瀏覽器向客戶端發(fā)起請(qǐng)求，如果 CDN 有緩存則直接返回;
• 如果 CDN 無緩存，則訪問反向代理服務(wù)器;
• 如果反向代理服務(wù)器有緩存則直接返回;
• 如果反向代理服務(wù)器無緩存或動(dòng)態(tài)請(qǐng)求，則訪問應(yīng)用服務(wù)器;
• 應(yīng)用服務(wù)器訪問進(jìn)程內(nèi)緩存;如果有緩存，則返回代理服務(wù)器，并緩存數(shù)據(jù)(動(dòng)態(tài)請(qǐng)求不緩存);
• 如果進(jìn)程內(nèi)緩存無數(shù)據(jù)，則讀取分布式緩存;并返回應(yīng)用服務(wù)器;應(yīng)用服務(wù)器將數(shù)據(jù)緩存到本地緩存(部分);
• 如果分布式緩存無數(shù)據(jù)，則應(yīng)用程序讀取數(shù)據(jù)庫(kù)數(shù)據(jù)，并放入分布式緩存;

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

如果應(yīng)用服務(wù)是單點(diǎn)應(yīng)用，那么進(jìn)程內(nèi)緩存當(dāng)然是緩存的首選方案。對(duì)于進(jìn)程內(nèi)緩存，其本來受限于內(nèi)存的大小的限制，以及進(jìn)程緩存更新后其他緩存無法得知，所以一般來說進(jìn)程緩存適用于:

• 數(shù)據(jù)量不是很大且更新頻率較低的數(shù)據(jù)。
• 如果更新頻繁的數(shù)據(jù)，也想使用進(jìn)程內(nèi)緩存，那么可以將其過期時(shí)間設(shè)置為較短的時(shí)間，或者設(shè)置較短的自動(dòng)刷新時(shí)間。

這種方案存在以下問題：

• 如果應(yīng)用服務(wù)是分布式系統(tǒng)，應(yīng)用節(jié)點(diǎn)之間無法共享緩存，存在數(shù)據(jù)不一致問題。
• 由于進(jìn)程內(nèi)緩存受限于內(nèi)存大小的限制，所以緩存不能無限擴(kuò)展。

5.3 使用分布式緩存

如果應(yīng)用服務(wù)是分布式系統(tǒng)，那么最簡(jiǎn)單的緩存方案就是直接使用分布式緩存。其應(yīng)用場(chǎng)景如圖所示：

Redis 用來存儲(chǔ)熱點(diǎn)數(shù)據(jù)，如果緩存不命中，則去查詢數(shù)據(jù)庫(kù)，并更新緩存。這種方案存在以下問題：

• 緩存服務(wù)如果掛了，這時(shí)應(yīng)用只能訪問數(shù)據(jù)庫(kù)，容易造成緩存雪崩。
• 訪問分布式緩存服務(wù)會(huì)有一定的 I/O 以及序列化反序列化的開銷，雖然性能很高，但是其終究沒有在內(nèi)存中查詢快。

5.4 使用多級(jí)緩存

單純使用進(jìn)程內(nèi)緩存和分布式緩存都存在各自的不足。如果需要更高的性能以及更好的可用性，我們可以將緩存設(shè)計(jì)為多級(jí)結(jié)構(gòu)。將最熱的數(shù)據(jù)使用進(jìn)程內(nèi)緩存存儲(chǔ)在內(nèi)存中，進(jìn)一步提升訪問速度。

這個(gè)設(shè)計(jì)思路在計(jì)算機(jī)系統(tǒng)中也存在，比如 CPU 使用 L1、L2、L3 多級(jí)緩存，用來減少對(duì)內(nèi)存的直接訪問，從而加快訪問速度。一般來說，多級(jí)緩存架構(gòu)使用二級(jí)緩存已可以滿足大部分業(yè)務(wù)需求，過多的分級(jí)會(huì)增加系統(tǒng)的復(fù)雜度以及維護(hù)的成本。因此，多級(jí)緩存不是分級(jí)越多越好，需要根據(jù)實(shí)際情況進(jìn)行權(quán)衡。

一個(gè)典型的二級(jí)緩存架構(gòu)，可以使用進(jìn)程內(nèi)緩存(如：Caffeine/Google Guava/Ehcache/HashMap)作為一級(jí)緩存;使用分布式緩存(如：Redis/Memcached)作為二級(jí)緩存。

5.4.1 多級(jí)緩存查詢

多級(jí)緩存查詢流程如下：

• 首先，查詢 L1 緩存，如果緩存命中，直接返回結(jié)果;如果沒有命中，執(zhí)行下一步。
• 接下來，查詢 L2 緩存，如果緩存命中，直接返回結(jié)果并回填 L1 緩存;如果沒有命中，執(zhí)行下一步。
• 最后，查詢數(shù)據(jù)庫(kù)，返回結(jié)果并依次回填 L2 緩存、L1 緩存。

5.4.2 多級(jí)緩存更新

對(duì)于 L1 緩存，如果有數(shù)據(jù)更新，只能刪除并更新所在機(jī)器上的緩存，其他機(jī)器只能通過超時(shí)機(jī)制來刷新緩存。超時(shí)設(shè)定可以有兩種策略:

• 設(shè)置成寫入后多少時(shí)間后過期;
• 設(shè)置成寫入后多少時(shí)間刷新。

對(duì)于 L2 緩存，如果有數(shù)據(jù)更新，其他機(jī)器立馬可見。但是，也必須要設(shè)置超時(shí)時(shí)間，其時(shí)間應(yīng)該比 L1 緩存的有效時(shí)間長(zhǎng)。為了解決進(jìn)程內(nèi)緩存不一致的問題，設(shè)計(jì)可以進(jìn)一步優(yōu)化;

通過消息隊(duì)列的發(fā)布、訂閱機(jī)制，可以通知其他應(yīng)用節(jié)點(diǎn)對(duì)進(jìn)程內(nèi)緩存進(jìn)行更新。使用這種方案，即使消息隊(duì)列服務(wù)掛了或不可靠，由于先執(zhí)行了數(shù)據(jù)庫(kù)更新，但進(jìn)程內(nèi)緩存過期，刷新緩存時(shí)，也能保證數(shù)據(jù)的最終一致性。

六、緩存問題

6.1 緩存雪崩

緩存雪崩是指緩存不可用或者大量緩存由于超時(shí)時(shí)間相同在同一時(shí)間段失效，大量請(qǐng)求直接訪問數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)壓力過大導(dǎo)致系統(tǒng)雪崩。

舉例來說，對(duì)于系統(tǒng) A，假設(shè)每天高峰期每秒 5000 個(gè)請(qǐng)求，本來緩存在高峰期可以扛住每秒 4000 個(gè)請(qǐng)求，但是緩存機(jī)器意外發(fā)生了全盤宕機(jī)。緩存掛了，此時(shí) 1 秒 5000 個(gè)請(qǐng)求全部落數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)必然扛不住，它會(huì)報(bào)一下警，然后就掛了。此時(shí)，如果沒有采用什么特別的方案來處理這個(gè)故障，DBA 很著急，重啟數(shù)據(jù)庫(kù)，但是數(shù)據(jù)庫(kù)立馬又被新的流量給打死了。

解決緩存雪崩的主要手段如下：

• 增加緩存系統(tǒng)可用性(事前)。例如：部署 Redis Cluster(主從+哨兵)，以實(shí)現(xiàn) Redis 的高可用，避免全盤崩潰。
• 采用多級(jí)緩存方案(事中)。例如：本地緩存(Ehcache/Caffine/Guava Cache) + 分布式緩存(Redis/ Memcached)。
• 限流、降級(jí)、熔斷方案(事中)，避免被流量打死。如：使用 Hystrix 進(jìn)行熔斷、降級(jí)。
• 緩存如果支持持久化，可以在恢復(fù)工作后恢復(fù)數(shù)據(jù)(事后)。如：Redis 支持持久化，一旦重啟，自動(dòng)從磁盤上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。

上面的解決方案簡(jiǎn)單來說，就是多級(jí)緩存方案。系統(tǒng)收到一個(gè)查詢請(qǐng)求，先查本地緩存，再查分布式緩存，最后查數(shù)據(jù)庫(kù)，只要命中，立即返回。

解決緩存雪崩的輔助手段如下：

• 監(jiān)控緩存，彈性擴(kuò)容。
• 緩存的過期時(shí)間可以取個(gè)隨機(jī)值。這么做是為避免緩存同時(shí)失效，使得數(shù)據(jù)庫(kù) IO 驟升。比如：以前是設(shè)置 10 分鐘的超時(shí)時(shí)間，那每個(gè) Key 都可以隨機(jī) 8-13 分鐘過期，盡量讓不同 Key 的過期時(shí)間不同。

6.2 緩存穿透

緩存穿透是指：查詢的數(shù)據(jù)在數(shù)據(jù)庫(kù)中不存在，那么緩存中自然也不存在。所以，應(yīng)用在緩存中查不到，則會(huì)去查詢數(shù)據(jù)庫(kù)。當(dāng)這樣的請(qǐng)求多了后，數(shù)據(jù)庫(kù)的壓力就會(huì)增大。

解決緩存穿透，一般有兩種方法：

1)緩存空值

對(duì)于返回為 NULL 的依然緩存，對(duì)于拋出異常的返回不進(jìn)行緩存。

采用這種手段的會(huì)增加我們緩存的維護(hù)成本，需要在插入緩存的時(shí)候刪除這個(gè)空緩存，當(dāng)然我們可以通過設(shè)置較短的超時(shí)時(shí)間來解決這個(gè)問題。

2)過濾不可能存在的數(shù)據(jù)

制定一些規(guī)則過濾一些不可能存在的數(shù)據(jù)。可以使用布隆過濾器(針對(duì)二進(jìn)制操作的數(shù)據(jù)結(jié)構(gòu)，所以性能高)，比如你的訂單 ID 明顯是在一個(gè)范圍 1-1000，如果不是 1-1000 之內(nèi)的數(shù)據(jù)那其實(shí)可以直接給過濾掉。

針對(duì)于一些惡意攻擊，攻擊帶過來的大量 key 是不存在的，那么我們采用第一種方案就會(huì)緩存大量不存在 key 的數(shù)據(jù)。此時(shí)我們采用第一種方案就不合適了，我們完全可以先對(duì)使用第二種方案進(jìn)行過濾掉這些 key。針對(duì)這種 key 異常多、請(qǐng)求重復(fù)率比較低的數(shù)據(jù)，我們就沒有必要進(jìn)行緩存，使用第二種方案直接過濾掉。而對(duì)于空數(shù)據(jù)的 key 有限的，重復(fù)率比較高的，我們則可以采用第一種方式進(jìn)行緩存。

6.3 緩存擊穿

緩存擊穿是指，熱點(diǎn)數(shù)據(jù)失效瞬間，大量請(qǐng)求直接訪問數(shù)據(jù)庫(kù)。例如，某些 key 是熱點(diǎn)數(shù)據(jù)，訪問非常頻繁。如果某個(gè) key 失效的瞬間，大量的請(qǐng)求過來，緩存未命中，然后去數(shù)據(jù)庫(kù)訪問，此時(shí)數(shù)據(jù)庫(kù)訪問量會(huì)急劇增加。

為了避免這個(gè)問題，我們可以采取下面的兩個(gè)手段:

• 分布式鎖：鎖住熱點(diǎn)數(shù)據(jù)的 key，避免大量線程同時(shí)訪問同一個(gè) key。
• 定時(shí)異步刷新：可以對(duì)部分?jǐn)?shù)據(jù)采取失效前自動(dòng)刷新的策略，而不是到期自動(dòng)淘汰。淘汰其實(shí)也是為了數(shù)據(jù)的時(shí)效性，所以采用自動(dòng)刷新也可以。

6.4 小結(jié)

上面逐一介紹了緩存使用中常見的問題。這里，從發(fā)生時(shí)間段的角度整體歸納一下緩存問題解決方案。

• 事前：Redis 高可用方案(Redis Cluster + 主從 + 哨兵)，避免緩存全面崩潰。
• 事中：(一)采用多級(jí)緩存方案，本地緩存(Ehcache/Caffine/Guava Cache) + 分布式緩存(Redis/ Memcached)。(二)限流 + 熔斷 + 降級(jí)(Hystrix)，避免極端情況下，數(shù)據(jù)庫(kù)被打死。
• 事后：Redis 持久化(RDB+AOF)，一旦重啟，自動(dòng)從磁盤上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。

分布式緩存 Memcached ，由于數(shù)據(jù)類型不如 Redis 豐富，并且不支持持久化、容災(zāi)。所以，一般會(huì)選擇 Redis 做分布式緩存。

七、緩存策略

7.1 緩存預(yù)熱

緩存預(yù)熱是指系統(tǒng)啟動(dòng)后，直接查詢熱點(diǎn)數(shù)據(jù)并緩存。這樣就可以避免用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫(kù)，然后再更新緩存的問題。

解決方案：

• 手動(dòng)刷新緩存：直接寫個(gè)緩存刷新頁面，上線時(shí)手工操作下。
• 應(yīng)用啟動(dòng)時(shí)刷新緩存：數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載。
• 定時(shí)異步刷新緩存。

7.2 如何緩存

7.2.1 不過期緩存

緩存更新模式：

• 開啟事務(wù);
• 寫 SQL;
• 提交事務(wù);
• 寫緩存;

不要把寫緩存操作放在事務(wù)中，尤其是寫分布式緩存。因?yàn)榫W(wǎng)絡(luò)抖動(dòng)可能導(dǎo)致寫緩存響應(yīng)時(shí)間很慢，引起數(shù)據(jù)庫(kù)事務(wù)阻塞。如果對(duì)緩存數(shù)據(jù)一致性要求不是那么高，數(shù)據(jù)量也不是很大，可以考慮定期全量同步緩存。

這種模式存在這樣的情況：存在事務(wù)成功，但緩存寫失敗的可能。但這種情況相對(duì)于上面的問題，影響較小。

7.2.2 過期緩存

采用懶加載。對(duì)于熱點(diǎn)數(shù)據(jù)，可以設(shè)置較短的緩存時(shí)間，并定期異步加載。

7.3 緩存更新

一般來說，系統(tǒng)如果不是嚴(yán)格要求緩存和數(shù)據(jù)庫(kù)保持一致性的話，盡量不要將讀請(qǐng)求和寫請(qǐng)求串行化。串行化可以保證一定不會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，但是它會(huì)導(dǎo)致系統(tǒng)的吞吐量大幅度下降。

一般來說緩存的更新有兩種情況:

• 先刪除緩存，再更新數(shù)據(jù)庫(kù);
• 先更新數(shù)據(jù)庫(kù)，再刪除緩存;

為什么是刪除緩存，而不是更新緩存呢?

你可以想想當(dāng)有多個(gè)并發(fā)的請(qǐng)求更新數(shù)據(jù)，你并不能保證更新數(shù)據(jù)庫(kù)的順序和更新緩存的順序一致，那就會(huì)出現(xiàn)數(shù)據(jù)庫(kù)中和緩存中數(shù)據(jù)不一致的情況。所以一般來說考慮刪除緩存。

先刪除緩存，再更新數(shù)據(jù)庫(kù);

對(duì)于一個(gè)更新操作簡(jiǎn)單來說，就是先去各級(jí)緩存進(jìn)行刪除，然后更新數(shù)據(jù)庫(kù)。這個(gè)操作有一個(gè)比較大的問題，在對(duì)緩存刪除完之后，有一個(gè)讀請(qǐng)求，這個(gè)時(shí)候由于緩存被刪除所以直接會(huì)讀庫(kù)，讀操作的數(shù)據(jù)是老的并且會(huì)被加載進(jìn)入緩存當(dāng)中，后續(xù)讀請(qǐng)求全部訪問的老數(shù)據(jù)。

對(duì)緩存的操作不論成功失敗都不能阻塞我們對(duì)數(shù)據(jù)庫(kù)的操作，那么很多時(shí)候刪除緩存可以用異步的操作，但是先刪除緩存不能很好的適用于這個(gè)場(chǎng)景。先刪除緩存也有一個(gè)好處是，如果對(duì)數(shù)據(jù)庫(kù)操作失敗了，那么由于先刪除的緩存，最多只是造成 Cache Miss。

1)先更新數(shù)據(jù)庫(kù)，再刪除緩存(注：更推薦使用這種策略)。

如果我們使用更新數(shù)據(jù)庫(kù)，再刪除緩存就能避免上面的問題。

但是同樣的引入了新的問題：假設(shè)執(zhí)行更新操作時(shí)，又接收到查詢請(qǐng)求，此時(shí)就會(huì)返回緩存中的老數(shù)據(jù)。更麻煩的是，如果數(shù)據(jù)庫(kù)更新操作執(zhí)行失敗，則緩存中可能永遠(yuǎn)是臟數(shù)據(jù)。

2)應(yīng)該選擇哪種更新策略

通過上面的內(nèi)容，我們知道，兩種更新策略都存在并發(fā)問題。

但是建議選擇先更新數(shù)據(jù)庫(kù)，再刪除緩存，因?yàn)槠洳l(fā)問題出現(xiàn)的概率可能非常低，因?yàn)檫@個(gè)條件需要發(fā)生在讀緩存時(shí)緩存失效，而且同時(shí)有一個(gè)并發(fā)寫操作。而實(shí)際上數(shù)據(jù)庫(kù)的寫操作會(huì)比讀操作慢得多，而且還要鎖表，而讀操作必需在寫操作前進(jìn)入數(shù)據(jù)庫(kù)操作，而又要晚于寫操作更新緩存，所有的這些條件都具備的概率基本并不大。

如果需要數(shù)據(jù)庫(kù)和緩存保證強(qiáng)一致性，則可以通過 2PC 或 Paxos 協(xié)議來實(shí)現(xiàn)。但是 2PC 太慢，而 Paxos 太復(fù)雜，所以如果不是非常重要的數(shù)據(jù)，不建議使用強(qiáng)一致性方案。更詳細(xì)的分析可以參考：分布式之?dāng)?shù)據(jù)庫(kù)和緩存雙寫一致性方案解析。

八、總結(jié)

最后，通過一張思維導(dǎo)圖來總結(jié)一下本文所述的知識(shí)點(diǎn)，幫助大家對(duì)緩存有一個(gè)系統(tǒng)性的認(rèn)識(shí)。