# 一、快取簡介

## 1.1 什麼是快取

快取就是資料交換的緩衝區。快取的本質是一個記憶體 Hash。快取是一種利用空間換時間的設計，其目標就是更快、更近：極大的提高。

-   將資料寫入/讀取速度更快的儲存（裝置）；
    
-   將資料快取到離應用最近的位置；
    
-   將資料快取到離使用者最近的位置。

快取是用於儲存資料的硬體或軟體的組成部分，以使得後續更快訪問相應的資料。快取中的資料可能是提前計算好的結果、資料的副本等。典型的應用場景：有 cpu cache, 磁碟 cache 等。本文中提及到快取主要是指網際網路應用中所使用的快取元件。

快取命中率是快取的重要度量指標，命中率越高越好。

> 快取命中率 = 從快取中讀取次數 / 總讀取次數

## 1.2 何時需要快取

引入快取，會增加系統的複雜度。所以，引入快取前，需要先權衡是否值得，考量點如下：

-   **CPU 開銷** \- 如果應用某個計算需要消耗大量 CPU，可以考慮快取其計算結果。典型場景：複雜的、頻繁呼叫的正則計算；分散式計算中間狀態等。
    
-   **IO 開銷** \- 如果資料庫連線池比較繁忙，可以考慮快取其查詢結果。

在資料層引入快取，有以下幾個好處：

-   提升資料讀取速度。
    
-   提升系統擴充套件能力，透過擴充套件快取，提升系統承載能力。
    
-   降低儲存成本，Cache+DB 的方式可以承擔原有需要多臺 DB 才能承擔的請求量，節省機器成本。

## 1.3 快取的基本原理

根據業務場景，通常快取有以下幾種使用方式：

-   懶漢式(讀時觸發)：先查詢 DB 裡的資料, 然後把相關的資料寫入 Cache。
    
-   飢餓式(寫時觸發)：寫入 DB 後, 然後把相關的資料也寫入 Cache。
    
-   定期重新整理：適合週期性的跑資料的任務，或者列表型的資料，而且不要求絕對實時性。

## 1.4 快取淘汰策略

快取淘汰的型別：

**1）基於空間**：設定快取空間大小。

**2）基於容量**：設定快取儲存記錄數。

**3）基於時間**

-   TTL（Time To Live，即存活期）快取資料從建立到過期的時間。
    
-   TTI（Time To Idle，即空閒期）快取資料多久沒被訪問的時間。

快取淘汰演算法：

**1）FIFO：先進先出**。在這種淘汰演算法中，先進入快取的會先被淘汰。這種可謂是最簡單的了，但是會導致我們命中率很低。試想一下我們如果有個訪問頻率很高的資料是所有資料第一個訪問的，而那些不是很高的是後面再訪問的，那這樣就會把我們的首個資料但是他的訪問頻率很高給擠出。

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

**3）LFU：最近最少頻率使用**。在這種演算法中又對上面進行了最佳化，利用額外的空間記錄每個資料的使用頻率，然後選出頻率最低進行淘汰。這樣就避免了 LRU 不能處理時間段的問題。

這三種快取淘汰演算法，實現複雜度一個比一個高，同樣的命中率也是一個比一個好。而我們一般來說選擇的方案居中即可，即實現成本不是太高，而命中率也還行的 LRU。

# 二、快取的分類

快取從部署角度，可以分為客戶端快取和服務端快取。

**客戶端快取**

-   HTTP 快取
    
-   瀏覽器快取
    
-   APP 快取（1、Android  2、IOS）

**服務端快取**

-   CDN 快取：存放 HTML、CSS、JS 等靜態資源。
    
-   反向代理快取：動靜分離，只快取使用者請求的靜態資源。
    
-   資料庫快取：資料庫（如 MySQL）自身一般也有快取，但因為命中率和更新頻率問題，不推薦使用。
    
-   程式內快取：快取應用字典等常用資料。
    
-   分散式快取：快取資料庫中的熱點資料。

其中，CDN 快取、反向代理快取、資料庫快取一般由專職人員維護（運維、DBA）。後端開發一般聚焦於程式內快取、分散式快取。

## 2.1 HTTP 快取

## 2.2 CDN 快取

CDN 將資料快取到離使用者物理距離最近的伺服器，使得使用者可以就近獲取請求內容。CDN 一般快取靜態資原始檔（頁面，指令碼，圖片，影片，檔案等）。

國內網路異常複雜，跨運營商的網路訪問會很慢。為了解決跨運營商或各地使用者訪問問題，可以在重要的城市，部署 CDN 應用。使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。

![](https://static001.geekbang.org/infoq/83/8316fc5de8ec25b25b3976a72b1eb816.png)

圖片引用自：[Why use a CDN](https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/)

### 2.1.1 CDN 原理

CDN 的基本原理是廣泛採用各種快取伺服器，將這些快取伺服器分佈到使用者訪問相對集中的地區或網路中，在使用者訪問網站時，利用全域性負載技術將使用者的訪問指向距離最近的工作正常的快取伺服器上，由快取伺服器直接響應使用者請求。

1）未部署 CDN 應用前的網路路徑：

-   **請求**：本機網路（區域網）=> 運營商網路 =\> 應用伺服器機房
    
-   **響應**：應用伺服器機房 => 運營商網路 =\> 本機網路（區域網）

在不考慮複雜網路的情況下，從請求到響應需要經過 3 個節點，6 個步驟完成一次使用者訪問操作。

2）部署 CDN 應用後網路路徑：

-   **請求**：本機網路（區域網） =\> 運營商網路
    
-   **響應**：運營商網路 =\> 本機網路（區域網）

在不考慮複雜網路的情況下，從請求到響應需要經過 2 個節點，2 個步驟完成一次使用者訪問操作。與不部署 CDN 服務相比，減少了 1 個節點，4 個步驟的訪問。極大的提高了系統的響應速度。

### 2.1.2 CDN 特點

**優點**

-   **本地 Cache 加速**：提升訪問速度，尤其含有大量圖片和靜態頁面站點；
    
-   **實現跨運營商的網路加速**：消除了不同運營商之間互聯的瓶頸造成的影響，實現了跨運營商的網路加速，保證不同網路中的使用者都能得到良好的訪問質量；
    
-   **遠端加速**：遠端訪問使用者根據 DNS 負載均衡技術智慧自動選擇 Cache 伺服器，選擇最快的 Cache 伺服器，加快遠端訪問的速度；
    
-   **頻寬最佳化**：自動生成伺服器的遠端 Mirror（映象）cache 伺服器，遠端使用者訪問時從 cache 伺服器上讀取資料，減少遠端訪問的頻寬、分擔網路流量、減輕原站點 WEB 伺服器負載等功能。
    
-   **叢集抗攻擊**：廣泛分佈的 CDN 節點加上節點之間的智慧冗餘機制，可以有效地預防駭客入侵以及降低各種 D.D.o.S 攻擊對網站的影響，同時保證較好的服務質量。

**缺點**

-   **不適宜快取動態資源**

> 解決方案：主要快取靜態資源，動態資源建立多級快取或準實時同步；

-   **存在資料的一致性問題**

> 1.解決方案（主要是在效能和資料一致性二者間尋找一個平衡）。
> 
> 2.設定快取失效時間（1 個小時，過期後同步資料）。
> 
> 3.針對資源設定版本號。

## 2.2 反向代理快取

反向代理（Reverse Proxy）方式是指以代理伺服器來接受 internet 上的連線請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給 internet 上請求連線的客戶端，此時代理伺服器對外就表現為一個反向代理伺服器。

![](https://static001.geekbang.org/infoq/73/73d1c1133e004acd263cc094a060543a.png)

### 2.2.1 反向代理快取原理

反向代理位於應用伺服器同一網路，處理所有對 WEB 伺服器的請求。反向代理快取的原理：

-   如果使用者請求的頁面在代理伺服器上有快取的話，代理伺服器直接將快取內容傳送給使用者。
    
-   如果沒有快取則先向 WEB 伺服器發出請求，取回資料，本地快取後再傳送給使用者。

這種方式透過降低向 WEB 伺服器的請求數，從而降低了 WEB 伺服器的負載。

反向代理快取一般針對的是靜態資源，而將動態資源請求轉發到應用伺服器處理。常用的快取應用伺服器有 Varnish，Ngnix，Squid。

### 2.2.2 反向代理快取比較

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

-   Varnish 和 Squid 是專業的 cache 服務，Ngnix 需要第三方模組支援；
    
-   Varnish 採用記憶體型快取，避免了頻繁在記憶體、磁碟中交換檔案，效能比 Squid 高；
    
-   Varnish 由於是記憶體 cache，所以對小檔案如 css、js、小圖片的支援很棒，後端的持久化快取可以採用的是 Squid 或 ATS；
    
-   Squid 功能全而大，適合於各種靜態的檔案快取，一般會在前端掛一個 HAProxy 或 Ngnix 做負載均衡跑多個例項；
    
-   Nginx 採用第三方模組 ncache 做的緩衝，效能基本達到 Varnish，一般作為反向代理使用，可以實現簡單的快取。

# 三、程式內快取

程式內快取是指應用內部的快取，標準的分散式系統，一般有多級快取構成。本地快取是離應用最近的快取，一般可以將資料快取到硬碟或記憶體。

-   **硬碟快取**：將資料快取到硬碟中，讀取時從硬碟讀取。原理是直接讀取本機檔案，減少了網路傳輸消耗，比透過網路讀取資料庫速度更快。可以應用在對速度要求不是很高，但需要大量快取儲存的場景。
    
-   **記憶體快取**：直接將資料儲存到本機記憶體中，透過程式直接維護快取物件，是訪問速度最快的方式。

常見的本地快取實現方案：HashMap、Guava Cache、Caffeine、Ehcache。

## 3.1 ConcurrentHashMap

最簡單的程式內快取可以透過 JDK 自帶的 HashMap 或 ConcurrentHashMap 實現。

-   適用場景：不需要淘汰的快取資料。
    
-   缺點：無法進行快取淘汰，記憶體會無限制的增長。

## 3.2 LRUHashMap

可以透過繼承 LinkedHashMap 來實現一個簡單的 LRUHashMap。重寫 removeEldestEntry 方法，即可完成一個簡單的最近最少使用演算法。

缺點：

-   鎖競爭嚴重，效能比較低。
    
-   不支援過期時間。
    
-   不支援自動重新整理。

## 3.3  Guava Cache

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

Guava Cache 對於過期的 Entry 並沒有馬上過期(也就是並沒有後臺執行緒一直在掃)，而是透過進行讀寫操作的時候進行過期處理，這樣做的好處是避免後臺執行緒掃描的時候進行全域性加鎖。直接透過查詢，判斷其是否滿足重新整理條件，進行重新整理。

## 3.4  Caffeine

Caffeine 實現了 W-TinyLFU(LFU + LRU 演算法的變種)，其命中率和讀寫吞吐量大大優於 Guava Cache。其實現原理較複雜，可以[參考你應該知道的快取進化史](https://juejin.cn/post/6844903660653117447#comment)。

## 3.5 Ehcache

EhCache 是一個純 Java 的程式內快取框架，具有快速、精幹等特點，是 Hibernate 中預設的 CacheProvider。

**優點**

-   快速、簡單;
    
-   支援多種快取策略：LRU、LFU、FIFO 淘汰演算法；
    
-   快取資料有兩級：記憶體和磁碟，因此無需擔心容量問題；
    
-   快取資料會在虛擬機器重啟的過程中寫入磁碟；
    
-   可以透過 RMI、可插入 API 等方式進行分散式快取；
    
-   具有快取和快取管理器的偵聽介面；
    
-   支援多快取管理器例項，以及一個例項的多個快取區域；
    
-   提供 Hibernate 的快取實現。

**缺點**

-   使用磁碟 Cache 的時候非常佔用磁碟空間；
    
-   不保證資料的安全；
    
-   雖然支援分散式快取，但效率不高（透過組播方式，在不同節點之間同步資料）。

## 3.6 程式內快取對比

常用程式內快取技術對比：

![](https://static001.geekbang.org/infoq/83/8372d8a42f5969260db683cfdbf7b45e.png)

-   **ConcurrentHashMap**：比較適合快取比較固定不變的元素，且快取的數量較小的。雖然從上面表格中比起來有點遜色，但是其由於是 JDK 自帶的類，在各種框架中依然有大量的使用，比如我們可以用來快取我們反射的 Method，Field 等等；也可以快取一些連結，防止其重複建立。在 Caffeine 中也是使用的 ConcurrentHashMap 來儲存元素。

-   **LRUMap**：如果不想引入第三方包，又想使用淘汰演算法淘汰資料，可以使用這個。

-   **Ehcache**：由於其 jar 包很大，較重量級。對於需要持久化和叢集的一些功能的，可以選擇 Ehcache。需要注意的是，雖然 Ehcache 也支援分散式快取，但是由於其節點間通訊方式為 rmi，表現不如 Redis，所以一般不建議用它來作為分散式快取。

-   **Guava Cache**：Guava 這個 jar 包在很多 Java 應用程式中都有大量的引入，所以很多時候其實是直接用就好了，並且其本身是輕量級的而且功能較為豐富，在不瞭解 Caffeine 的情況下可以選擇 Guava Cache。

-   **Caffeine**：其在命中率，讀寫效能上都比 Guava Cache 好很多，並且其 API 和 Guava cache 基本一致，甚至會多一點。在真實環境中使用 Caffeine，取得過不錯的效果。

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

# 四、分散式快取

分散式快取解決了程式內快取最大的問題：如果應用是分散式系統，節點之間無法共享彼此的程式內快取。分散式快取的應用場景：

-   快取經過複雜計算得到的資料。
    
-   快取系統中頻繁訪問的熱點資料，減輕資料庫壓力。

不同分散式快取的實現原理往往有比較大的差異。本文主要針對 Memcached 和 Redis 進行說明。

## 4.1 Memcached

Memcached 是一個高效能，分散式記憶體物件快取系統，透過在記憶體裡維護一個統一的巨大的 Hash 表，它能夠用來儲存各種格式的資料，包括影像、影片、檔案以及資料庫檢索的結果等。

簡單的說就是：將資料快取到記憶體中，然後從記憶體中讀取，從而大大提高讀取速度。

### 4.1.1 Memcached 特性

-   **使用實體記憶體作為快取區，可獨立執行在伺服器上**。每個程式最大 2G，如果想快取更多的資料，可以開闢更多的 Memcached 程式（不同埠）或者使用分散式 Memcached 進行快取，將資料快取到不同的物理機或者虛擬機器上。

-   **使用 key-value 的方式來儲存資料**。這是一種單索引的結構化資料組織形式，可使資料項查詢時間複雜度為 O(1)。

-   **協議簡單，基於文字行的協議**。直接透過 telnet 在 Memcached 伺服器上可進行存取資料操作，簡單，方便多種快取參考此協議；

-   **基於 libevent 高效能通訊**。Libevent 是一套 利用 C 開發的程式庫，它將 BSD 系統的 kqueue,Linux 系統的 epoll 等事件處理功能封裝成一個介面，與傳統的 select 相比，提高了效能。

-   **分散式能力取決於 Memcached 客戶端，伺服器之間互不通訊**。各個 Memcached 伺服器之間互不通訊，各自獨立存取資料，不共享任何資訊。伺服器並不具有分散式功能，分散式部署取決於 Memcached 客戶端。

-   **採用 LRU 快取淘汰策略**。在 Memcached 記憶體儲資料項時，可以指定它在快取的失效時間，預設為永久。當 Memcached 伺服器用完分配的內時，失效的資料被首先替換，然後也是最近未使用的資料。在 LRU 中，Memcached 使用的是一種 Lazy Expiration 策略，自己不會監控存入的 key/vlue 對是否過期，而是在獲取 key 值時檢視記錄的時間戳，檢查 key/value 對空間是否過期，這樣可減輕伺服器的負載。

-   **內建了一套高效的記憶體管理演算法**。這套記憶體管理效率很高，而且不會造成記憶體碎片，但是它最大的缺點就是會導致空間浪費。當記憶體滿後，透過 LRU 演算法自動刪除不使用的快取。

-   **不支援持久化**。Memcached 沒有考慮資料的容災問題，重啟服務，所有資料會丟失。

### 4.1.2 Memcached 工作原理

**1）記憶體管理**

Memcached 利用 slab allocation 機制來分配和管理記憶體，它按照預先規定的大小，將分配的記憶體分割成特定長度的記憶體塊，再把尺寸相同的記憶體塊分成組，資料在存放時，根據鍵值 大小去匹配 slab 大小，找就近的 slab 存放，所以存在空間浪費現象。

這套記憶體管理效率很高，而且不會造成記憶體碎片，但是它最大的缺點就是會導致空間浪費。

**2）快取淘汰策略**

Memcached 的快取淘汰策略是 LRU + 到期失效策略。

當你在 Memcached 記憶體儲資料項時，你有可能會指定它在快取的失效時間，預設為永久。當 Memcached 伺服器用完分配的內時，失效的資料被首先替換，然後是最近未使用的資料。

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

**3）分割槽**

Memcached 伺服器之間彼此不通訊，它的分散式能力是依賴客戶端來實現。具體來說，就是在客戶端實現一種演算法，根據 key 來計算出資料應該向哪個伺服器節點讀/寫。

而這種選取叢集節點的演算法常見的有三種：

-   **雜湊取餘演算法**：使用公式：Hash（key）% N 計算出 雜湊值 來決定資料對映到哪一個節點。

-   **一致性雜湊演算法**：可以很好的解決 穩定性問題，可以將所有的 儲存節點 排列在 首尾相接 的 Hash 環上，每個 key 在計算 Hash 後會 順時針 找到 臨接 的 儲存節點 存放。而當有節點 加入 或 退出 時，僅影響該節點在 Hash 環上 順時針相鄰 的 後續節點。

-   **虛擬 Hash 槽演算法**：使用 分散度良好 的 雜湊函式 把所有資料 對映 到一個 固定範圍 的 整數集合 中，整數定義為 槽（slot），這個範圍一般 遠遠大於 節點數。槽 是叢集內 資料管理 和 遷移 的 基本單位。採用 大範圍槽 的主要目的是為了方便 資料拆分 和 叢集擴充套件。每個節點會負責 一定數量的槽。

## 4.2 Redis

Redis 是一個開源（BSD 許可）的，基於記憶體的，多資料結構儲存系統。可以用作資料庫、快取和訊息中介軟體。

Redis 還可以使用客戶端分片來擴充套件寫效能。內建了 複製（replication），LUA 指令碼（Lua scripting），LRU 驅動事件（LRU eviction），事務（transactions） 和不同級別的 磁碟持久化（persistence）， 並透過 Redis 哨兵（Sentinel）和自動分割槽（Cluster）提供高可用性（high availability）。

### 4.2.1 Redis 特性

-   支援多種資料型別 \- string、Hash、list、set、sorted set。

-   支援多種資料淘汰策略；

> **volatile-lru**：從已設定過期時間的資料集中挑選最近最少使用的資料淘汰；
> 
> **volatile-ttl **：從已設定過期時間的資料集中挑選將要過期的資料淘汰；
> 
> **volatile-random**：從已設定過期時間的資料集中任意選擇資料淘汰；
> 
> **allkeys-lru**：從所有資料集中挑選最近最少使用的資料淘汰；
> 
> **allkeys-random**：從所有資料集中任意選擇資料進行淘汰；
> 
> **noeviction** ：禁止驅逐資料。

-   提供兩種持久化方式 \- RDB 和 AOF。

-   透過 Redis cluster 提供叢集模式。

### 4.2.2 Redis 原理

**1）快取淘汰**

Redis 有兩種資料淘汰實現；

-   消極方式：訪問 Redis key 時，如果發現它已經失效，則刪除它
    
-   積極方式：週期性從設定了失效時間的 key 中，根據淘汰策略，選擇一部分失效的 key 進行刪除。

**2）分割槽**

-   Redis Cluster 叢集包含 16384 個虛擬 Hash 槽，它透過一個高效的演算法來計算 key 屬於哪個 Hash 槽。
    
-   Redis Cluster 支援請求分發 - 節點在接到一個命令請求時，會先檢測這個命令請求要處理的鍵所在的槽是否由自己負責，如果不是的話，節點將向客戶端返回一個 MOVED 錯誤，MOVED 錯誤攜帶的資訊可以指引客戶端將請求重定向至正在負責相關槽的節點。

**3）主從複製**

-   Redis 2.8 後支援非同步複製。它有兩種模式：

> **完整重同步**（full resychronization） - 用於初次複製。執行步驟與 SYNC 命令基本一致。
> 
> **部分重同步**（partial resychronization） - 用於斷線後重複製。如果條件允許，主伺服器可以將主從伺服器連線斷開期間執行的寫命令傳送給從伺服器，從伺服器只需接收並執行這些寫命令，即可將主從伺服器的資料庫狀態保持一致。

-   叢集中每個節點都會定期向叢集中的其他節點傳送 PING 訊息，以此來檢測對方是否線上。
    
-   如果一個主節點被認為下線，則在其從節點中，根據 Raft 演算法，選舉出一個節點，升級為主節點。

**4）資料一致性**

-   Redis 不保證強一致性，因為這會使得叢集效能大大降低。
    
-   Redis 是透過非同步複製來實現最終一致性。

## 4.3  分散式快取對比

不同的分散式快取功能特性和實現原理方面有很大的差異，因此他們所適應的場景也有所不同。

![](https://static001.geekbang.org/infoq/ae/ae95d7cd995e59492bc2282477d49129.png)

這裡選取三個比較出名的分散式快取（MemCache，Redis，Tair）來作為比較：

![](https://static001.geekbang.org/infoq/a4/a4833962061186370688099afe0e3c69.png)

-   **MemCache**：只適合基於記憶體的快取框架；且不支援資料持久化和容災。
    
-   **Redis**：支援豐富的資料結構，讀寫效能很高，但是資料全記憶體，必須要考慮資源成本，支援持久化。
    
-   **Tair**：支援豐富的資料結構，讀寫效能較高，部分型別比較慢，理論上容量可以無限擴充。

總結：如果服務對延遲比較敏感，Map/Set 資料也比較多的話，比較適合 Redis。如果服務需要放入快取量的資料很大，對延遲又不是特別敏感的話，那就可以選擇 Memcached。

# 五、多級快取

## 5.1 整體快取框架

通常，一個大型軟體系統的快取採用多級快取方案：

![](https://static001.geekbang.org/infoq/ec/ec3c8e33d928d79a3126654ea4ec20bc.png)

請求過程：

-   瀏覽器向客戶端發起請求，如果 CDN 有快取則直接返回；
    
-   如果 CDN 無快取，則訪問反向代理伺服器；
    
-   如果反向代理伺服器有快取則直接返回；
    
-   如果反向代理伺服器無快取或動態請求，則訪問應用伺服器；
    
-   應用伺服器訪問程式內快取；如果有快取，則返回代理伺服器，並快取資料（動態請求不快取）；
    
-   如果程式內快取無資料，則讀取分散式快取；並返回應用伺服器；應用伺服器將資料快取到本地快取（部分）；
    
-   如果分散式快取無資料，則應用程式讀取資料庫資料，並放入分散式快取；

## 5.2 使用程式內快取

如果應用服務是單點應用，那麼程式內快取當然是快取的首選方案。對於程式內快取，其本來受限於記憶體的大小的限制，以及程式快取更新後其他快取無法得知，所以一般來說程式快取適用於:

-   資料量不是很大且更新頻率較低的資料。
    
-   如果更新頻繁的資料，也想使用程式內快取，那麼可以將其過期時間設定為較短的時間，或者設定較短的自動重新整理時間。

這種方案存在以下問題：

-   如果應用服務是分散式系統，應用節點之間無法共享快取，存在資料不一致問題。
    
-   由於程式內快取受限於記憶體大小的限制，所以快取不能無限擴充套件。

## 5.3 使用分散式快取

如果應用服務是分散式系統，那麼最簡單的快取方案就是直接使用分散式快取。其應用場景如圖所示：

![](https://static001.geekbang.org/infoq/a6/a6c5c2acb417a05e363d199535a1f37f.png)

Redis 用來儲存熱點資料，如果快取不命中，則去查詢資料庫，並更新快取。這種方案存在以下問題：

-   快取服務如果掛了，這時應用只能訪問資料庫，容易造成快取雪崩。
    
-   訪問分散式快取服務會有一定的 I/O 以及序列化反序列化的開銷，雖然效能很高，但是其終究沒有在記憶體中查詢快。

## 5.4 使用多級快取

單純使用程式內快取和分散式快取都存在各自的不足。如果需要更高的效能以及更好的可用性，我們可以將快取設計為多級結構。將最熱的資料使用程式內快取儲存在記憶體中，進一步提升訪問速度。

這個設計思路在計算機系統中也存在，比如 CPU 使用 L1、L2、L3 多級快取，用來減少對記憶體的直接訪問，從而加快訪問速度。一般來說，多級快取架構使用二級快取已可以滿足大部分業務需求，過多的分級會增加系統的複雜度以及維護的成本。因此，多級快取不是分級越多越好，需要根據實際情況進行權衡。

一個典型的二級快取架構，可以使用程式內快取（如：Caffeine/Google Guava/Ehcache/HashMap）作為一級快取；使用分散式快取（如：Redis/Memcached）作為二級快取。

### 5.4.1 多級快取查詢

![](https://static001.geekbang.org/infoq/50/50361fd1f0dd52f9950f519df0a60a08.png)

多級快取查詢流程如下：

-   首先，查詢 L1 快取，如果快取命中，直接返回結果；如果沒有命中，執行下一步。
    
-   接下來，查詢 L2 快取，如果快取命中，直接返回結果並回填 L1 快取；如果沒有命中，執行下一步。
    
-   最後，查詢資料庫，返回結果並依次回填 L2 快取、L1 快取。

### 5.4.2 多級快取更新

對於 L1 快取，如果有資料更新，只能刪除並更新所在機器上的快取，其他機器只能透過超時機制來重新整理快取。超時設定可以有兩種策略:

-   設定成寫入後多少時間後過期；
    
-   設定成寫入後多少時間重新整理。

對於 L2 快取，如果有資料更新，其他機器立馬可見。但是，也必須要設定超時時間，其時間應該比 L1 快取的有效時間長。為了解決程式內快取不一致的問題，設計可以進一步最佳化；

![](https://static001.geekbang.org/infoq/e0/e04ba716475a2ccd2df8efc836e80803.png)

透過訊息佇列的釋出、訂閱機制，可以通知其他應用節點對程式內快取進行更新。使用這種方案，即使訊息佇列服務掛了或不可靠，由於先執行了資料庫更新，但程式內快取過期，重新整理快取時，也能保證資料的最終一致性。

# 六、快取問題

## 6.1 快取雪崩

快取雪崩是指快取不可用或者大量快取由於超時時間相同在同一時間段失效，大量請求直接訪問資料庫，資料庫壓力過大導致系統雪崩。

舉例來說，對於系統 A，假設每天高峰期每秒 5000 個請求，本來快取在高峰期可以扛住每秒 4000 個請求，但是快取機器意外發生了全盤當機。快取掛了，此時 1 秒 5000 個請求全部落資料庫，資料庫必然扛不住，它會報一下警，然後就掛了。此時，如果沒有采用什麼特別的方案來處理這個故障，DBA 很著急，重啟資料庫，但是資料庫立馬又被新的流量給打死了。

解決快取雪崩的主要手段如下：

-   **增加快取系統可用性（事前）**。例如：部署 Redis Cluster（主從+哨兵），以實現 Redis 的高可用，避免全盤崩潰。
    
-   **採用多級快取方案（事中）**。例如：本地快取（Ehcache/Caffine/Guava Cache） + 分散式快取（Redis/ Memcached）。
    
-   **限流、降級、熔斷方案**（事中），避免被流量打死。如：使用 Hystrix 進行熔斷、降級。
    
-   快取如果支援**持久化**，可以在恢復工作後恢復資料（事後）。如：Redis 支援持久化，一旦重啟，自動從磁碟上載入資料，快速恢復快取資料。

上面的解決方案簡單來說，就是多級快取方案。系統收到一個查詢請求，先查本地快取，再查分散式快取，最後查資料庫，只要命中，立即返回。

解決快取雪崩的輔助手段如下：

-   監控快取，彈性擴容。
    
-   快取的過期時間可以取個隨機值。這麼做是為避免快取同時失效，使得資料庫 IO 驟升。比如：以前是設定 10 分鐘的超時時間，那每個 Key 都可以隨機 8-13 分鐘過期，儘量讓不同 Key 的過期時間不同。

## 6.2 快取穿透

快取穿透是指：查詢的資料在資料庫中不存在，那麼快取中自然也不存在。所以，應用在快取中查不到，則會去查詢資料庫。當這樣的請求多了後，資料庫的壓力就會增大。

解決快取穿透，一般有兩種方法：

**1）快取空值**

對於返回為 NULL 的依然快取，對於丟擲異常的返回不進行快取。

![](https://static001.geekbang.org/infoq/9d/9d6495431f39aa7f8b2ebce3bdce636e.png)

採用這種手段的會增加我們快取的維護成本，需要在插入快取的時候刪除這個空快取，當然我們可以透過設定較短的超時時間來解決這個問題。

**2）過濾不可能存在的資料**

![](https://static001.geekbang.org/infoq/7b/7b42c2537fddc6d2f7e4f8a014f4ecf7.png)

制定一些規則過濾一些不可能存在的資料。可以使用布隆過濾器（針對二進位制操作的資料結構，所以效能高），比如你的訂單 ID 明顯是在一個範圍 1-1000，如果不是 1-1000 之內的資料那其實可以直接給過濾掉。

> 針對於一些惡意攻擊，攻擊帶過來的大量 key 是不存在的，那麼我們採用第一種方案就會快取大量不存在 key 的資料。此時我們採用第一種方案就不合適了，我們完全可以先對使用第二種方案進行過濾掉這些 key。針對這種 key 異常多、請求重複率比較低的資料，我們就沒有必要進行快取，使用第二種方案直接過濾掉。而對於空資料的 key 有限的，重複率比較高的，我們則可以採用第一種方式進行快取。

## 6.3 快取擊穿

快取擊穿是指，熱點資料失效瞬間，大量請求直接訪問資料庫。例如，某些 key 是熱點資料，訪問非常頻繁。如果某個 key 失效的瞬間，大量的請求過來，快取未命中，然後去資料庫訪問，此時資料庫訪問量會急劇增加。

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

-   **分散式鎖**：鎖住熱點資料的 key，避免大量執行緒同時訪問同一個 key。
    
-   **定時非同步重新整理**：可以對部分資料採取失效前自動重新整理的策略，而不是到期自動淘汰。淘汰其實也是為了資料的時效性，所以採用自動重新整理也可以。

## 6.4 小結

上面逐一介紹了快取使用中常見的問題。這裡，從發生時間段的角度整體歸納一下快取問題解決方案。

-   **事前**：Redis 高可用方案（Redis Cluster + 主從 + 哨兵），避免快取全面崩潰。
    
-   **事中**：（一）採用多級快取方案，本地快取（Ehcache/Caffine/Guava Cache） + 分散式快取（Redis/ Memcached）。（二）限流 + 熔斷 + 降級（Hystrix），避免極端情況下，資料庫被打死。
    
-   **事後**：Redis 持久化（RDB+AOF），一旦重啟，自動從磁碟上載入資料，快速恢復快取資料。

分散式快取 Memcached ，由於資料型別不如 Redis 豐富，並且不支援持久化、容災。所以，一般會選擇 Redis 做分散式快取。

# 七、快取策略

## 7.1 快取預熱

快取預熱是指系統啟動後，直接查詢熱點資料並快取。這樣就可以避免使用者請求的時候，先查詢資料庫，然後再更新快取的問題。

解決方案：

-   手動重新整理快取：直接寫個快取重新整理頁面，上線時手工操作下。
    
-   應用啟動時重新整理快取：資料量不大，可以在專案啟動的時候自動進行載入。
    
-   定時非同步重新整理快取。

## 7.2 如何快取

### 7.2.1 不過期快取

-   快取更新模式：
    
-   開啟事務；
    
-   寫 SQL；
    
-   提交事務；
    
-   寫快取；

不要把寫快取操作放在事務中，尤其是寫分散式快取。因為網路抖動可能導致寫快取響應時間很慢，引起資料庫事務阻塞。如果對快取資料一致性要求不是那麼高，資料量也不是很大，可以考慮定期全量同步快取。

這種模式存在這樣的情況：存在事務成功，但快取寫失敗的可能。但這種情況相對於上面的問題，影響較小。

### 7.2.2 過期快取

採用懶載入。對於熱點資料，可以設定較短的快取時間，並定期非同步載入。

## 7.3 快取更新

一般來說，系統如果不是嚴格要求快取和資料庫保持一致性的話，儘量不要將讀請求和寫請求序列化。序列化可以保證一定不會出現資料不一致的情況，但是它會導致系統的吞吐量大幅度下降。

一般來說快取的更新有兩種情況:

-   先刪除快取，再更新資料庫；
    
-   先更新資料庫，再刪除快取；

> 為什麼是刪除快取，而不是更新快取呢？
> 
> 你可以想想當有多個併發的請求更新資料，你並不能保證更新資料庫的順序和更新快取的順序一致，那就會出現資料庫中和快取中資料不一致的情況。所以一般來說考慮刪除快取。

-   先刪除快取，再更新資料庫；

對於一個更新操作簡單來說，就是先去各級快取進行刪除，然後更新資料庫。這個操作有一個比較大的問題，在對快取刪除完之後，有一個讀請求，這個時候由於快取被刪除所以直接會讀庫，讀操作的資料是老的並且會被載入進入快取當中，後續讀請求全部訪問的老資料。

![](https://static001.geekbang.org/infoq/3d/3de39290a6147f3dbf694a82840c2153.png)

對快取的操作不論成功失敗都不能阻塞我們對資料庫的操作，那麼很多時候刪除快取可以用非同步的操作，但是先刪除快取不能很好的適用於這個場景。先刪除快取也有一個好處是，如果對資料庫操作失敗了，那麼由於先刪除的快取，最多隻是造成 Cache Miss。

**1）先更新資料庫，再刪除快取**（注：更推薦使用這種策略）。

如果我們使用更新資料庫，再刪除快取就能避免上面的問題。

但是同樣的引入了新的問題：假設執行更新操作時，又接收到查詢請求，此時就會返回快取中的老資料。更麻煩的是，如果資料庫更新操作執行失敗，則快取中可能永遠是髒資料。

**2）應該選擇哪種更新策略**

透過上面的內容，我們知道，兩種更新策略都存在併發問題。

但是建議選擇先更新資料庫，再刪除快取，因為其併發問題出現的機率可能非常低，因為這個條件需要發生在讀快取時快取失效，而且同時有一個併發寫操作。而實際上資料庫的寫操作會比讀操作慢得多，而且還要鎖表，而讀操作必需在寫操作前進入資料庫操作，而又要晚於寫操作更新快取，所有的這些條件都具備的機率基本並不大。

如果需要資料庫和快取保證強一致性，則可以透過 2PC 或 Paxos 協議來實現。但是 2PC 太慢，而 Paxos 太複雜，所以如果不是非常重要的資料，不建議使用強一致性方案。更詳細的分析可以參考：[分散式之資料庫和快取雙寫一致性方案解析](https://www.cnblogs.com/rjzheng/p/9041659.html)。

# 八、總結

最後，透過一張思維導圖來總結一下本文所述的知識點，幫助大家對快取有一個系統性的認識。

![](https://static001.geekbang.org/infoq/75/75a148579a1918e0ca95e459bd49ac79.png)

# 九、參考資料

1、[《大型網站技術架構：核心原理與案例分析》](https://book.douban.com/subject/25723064/)

2、[你應該知道的快取進化史](https://juejin.cn/post/6844903660653117447)

3、[如何優雅的設計和使用快取？](https://juejin.cn/post/6844903665845665805)

4、[理解分散式系統中的快取架構(上)](https://www.jianshu.com/p/73ce0ef820f9)

5、[快取那些事](https://tech.meituan.com/2017/03/17/cache-about.html)

6、[分散式之資料庫和快取雙寫一致性方案解析](https://www.cnblogs.com/rjzheng/p/9041659.html)

> 作者：vivo網際網路伺服器團隊-Zhang Peng

解析分散式系統的快取設計

相關文章