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

一、緩存簡介

1.1 什么是緩存

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

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

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

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

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

1.2 何時需要緩存

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

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

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

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

1.3 緩存的基本原理

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

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

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

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

1.4 緩存淘汰策略

緩存淘汰的類型：

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

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

3)基于時間

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

緩存淘汰算法：

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

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

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

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

二、緩存的分類

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

客戶端緩存

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

服務(wù)端緩存

• CDN 緩存：存放 HTML、CSS、JS 等靜態(tài)資源。
• 反向代理緩存：動靜分離，只緩存用戶請求的靜態(tài)資源。
• 數(shù)據(jù)庫緩存：數(shù)據(jù)庫(如 MySQL)自身一般也有緩存，但因為命中率和更新頻率問題，不推薦使用。
• 進程內(nèi)緩存：緩存應(yīng)用字典等常用數(shù)據(jù)。
• 分布式緩存：緩存數(shù)據(jù)庫中的熱點數(shù)據(jù)。

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

2.1 HTTP 緩存

2.2 CDN 緩存

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

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

圖片引用自：Why use a CDN

2.1.1 CDN 原理

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

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

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

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

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

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

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

2.1.2 CDN 特點

優(yōu)點

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

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

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

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

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

缺點

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

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

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

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

2.2 反向代理緩存

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

2.2.1 反向代理緩存原理

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

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

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

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

2.2.2 反向代理緩存比較

常用的代理緩存有 Varnish，Squid，Ngnix，簡單比較如下：

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

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

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

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

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

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

3.1 ConcurrentHashMap

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

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

缺點：無法進行緩存淘汰，內(nèi)存會無限制的增長。

3.2 LRUHashMap

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

缺點：

• 鎖競爭嚴(yán)重，性能比較低。
• 不支持過期時間。
• 不支持自動刷新。

3.3 Guava Cache

解決了LRUHashMap 中的幾個缺點。Guava Cache 采用了類似 ConcurrentHashMap 的思想，分段加鎖，減少鎖競爭。

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

3.4 Caffeine

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

3.5 Ehcache

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

優(yōu)點

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

缺點

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

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

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

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

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

四、分布式緩存

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

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

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

4.1 Memcached

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

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

4.1.1 Memcached 特性

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

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

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

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

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

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

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

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

4.1.2 Memcached 工作原理

1)內(nèi)存管理

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

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

2)緩存淘汰策略

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

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

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

3)分區(qū)

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

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

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

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

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

4.2 Redis

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

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

4.2.1 Redis 特性

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

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

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

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

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

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

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

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

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

4.2.2 Redis 原理

1)緩存淘汰

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

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

2)分區(qū)

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

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

3)主從復(fù)制

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

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

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

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

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

Redis 不保證強一致性，因為這會使得集群性能大大降低。

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

4.3 分布式緩存對比

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

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

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

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

五、多級緩存

5.1 整體緩存框架

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

請求過程：

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

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

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

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

這種方案存在以下問題：

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

5.3 使用分布式緩存

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

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

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

5.4 使用多級緩存

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

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

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

5.4.1 多級緩存查詢

多級緩存查詢流程如下：

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

5.4.2 多級緩存更新

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

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

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

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

六、緩存問題

6.1 緩存雪崩

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

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

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

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

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

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

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

6.2 緩存穿透

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

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

1)緩存空值

對于返回為 NULL 的依然緩存，對于拋出異常的返回不進行緩存。

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

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

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

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

6.3 緩存擊穿

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

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

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

6.4 小結(jié)

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

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

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

七、緩存策略

7.1 緩存預(yù)熱

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

解決方案：

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

7.2 如何緩存

7.2.1 不過期緩存

緩存更新模式：

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

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

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

7.2.2 過期緩存

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

7.3 緩存更新

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

八、總結(jié)

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