解析分布式系統的緩存設計

一、緩存簡介

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 應用。使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。

圖片引用自：Why use a 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 上請求連接的客戶端，此時代理服務器對外就表現為一個反向代理服務器。

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。其實現原理較復雜，可以參考你應該知道的緩存進化史。

3.5 Ehcache

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

優點

• 快速、簡單;

• 支持多種緩存策略：LRU、LFU、FIFO 淘汰算法；

• 緩存數據有兩級：內存和磁盤，因此無需擔心容量問題；

• 緩存數據會在虛擬機重啟的過程中寫入磁盤；

• 可以通過 RMI、可插入 API 等方式進行分布式緩存；

• 具有緩存和緩存管理器的偵聽接口；

• 支持多緩存管理器實例，以及一個實例的多個緩存區域；

• 提供 Hibernate 的緩存實現。

缺點

• 使用磁盤 Cache 的時候非常占用磁盤空間；

• 不保證數據的安全；

• 雖然支持分布式緩存，但效率不高（通過組播方式，在不同節點之間同步數據）。

3.6 進程內緩存對比

常用進程內緩存技術對比：

• 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  分布式緩存對比

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

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

• MemCache：只適合基於內存的緩存框架；且不支持數據持久化和容災。

• Redis：支持豐富的數據結構，讀寫性能很高，但是數據全內存，必須要考慮資源成本，支持持久化。

• Tair：支持豐富的數據結構，讀寫性能較高，部分類型比較慢，理論上容量可以無限擴充。

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

五、多級緩存

5.1 整體緩存框架

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

請求過程：

• 瀏覽器向客戶端發起請求，如果 CDN 有緩存則直接返回；

• 如果 CDN 無緩存，則訪問反向代理服務器；

• 如果反向代理服務器有緩存則直接返回；

• 如果反向代理服務器無緩存或動態請求，則訪問應用服務器；

• 應用服務器訪問進程內緩存；如果有緩存，則返回代理服務器，並緩存數據（動態請求不緩存）；

• 如果進程內緩存無數據，則讀取分布式緩存；並返回應用服務器；應用服務器將數據緩存到本地緩存（部分）；

• 如果分布式緩存無數據，則應用程序讀取數據庫數據，並放入分布式緩存；

5.2 使用進程內緩存

如果應用服務是單點應用，那么進程內緩存當然是緩存的首選方案。對於進程內緩存，其本來受限於內存的大小的限制，以及進程緩存更新后其他緩存無法得知，所以一般來說進程緩存適用於:

• 數據量不是很大且更新頻率較低的數據。

• 如果更新頻繁的數據，也想使用進程內緩存，那么可以將其過期時間設置為較短的時間，或者設置較短的自動刷新時間。

這種方案存在以下問題：

• 如果應用服務是分布式系統，應用節點之間無法共享緩存，存在數據不一致問題。

• 由於進程內緩存受限於內存大小的限制，所以緩存不能無限擴展。

5.3 使用分布式緩存

如果應用服務是分布式系統，那么最簡單的緩存方案就是直接使用分布式緩存。其應用場景如圖所示：

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

• 緩存服務如果掛了，這時應用只能訪問數據庫，容易造成緩存雪崩。

• 訪問分布式緩存服務會有一定的 I/O 以及序列化反序列化的開銷，雖然性能很高，但是其終究沒有在內存中查詢快。

5.4 使用多級緩存

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

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

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

5.4.1 多級緩存查詢

多級緩存查詢流程如下：

• 首先，查詢 L1 緩存，如果緩存命中，直接返回結果；如果沒有命中，執行下一步。

• 接下來，查詢 L2 緩存，如果緩存命中，直接返回結果並回填 L1 緩存；如果沒有命中，執行下一步。

• 最后，查詢數據庫，返回結果並依次回填 L2 緩存、L1 緩存。

5.4.2 多級緩存更新

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

• 設置成寫入后多少時間后過期；

• 設置成寫入后多少時間刷新。

對於 L2 緩存，如果有數據更新，其他機器立馬可見。但是，也必須要設置超時時間，其時間應該比 L1 緩存的有效時間長。為了解決進程內緩存不一致的問題，設計可以進一步優化；

通過消息隊列的發布、訂閱機制，可以通知其他應用節點對進程內緩存進行更新。使用這種方案，即使消息隊列服務掛了或不可靠，由於先執行了數據庫更新，但進程內緩存過期，刷新緩存時，也能保證數據的最終一致性。

六、緩存問題

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 的依然緩存，對於拋出異常的返回不進行緩存。

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

2）過濾不可能存在的數據

制定一些規則過濾一些不可能存在的數據。可以使用布隆過濾器（針對二進制操作的數據結構，所以性能高），比如你的訂單 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 緩存更新

一般來說，系統如果不是嚴格要求緩存和數據庫保持一致性的話，盡量不要將讀請求和寫請求串行化。串行化可以保證一定不會出現數據不一致的情況，但是它會導致系統的吞吐量大幅度下降。

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

• 先刪除緩存，再更新數據庫；

• 先更新數據庫，再刪除緩存；

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

你可以想想當有多個並發的請求更新數據，你並不能保證更新數據庫的順序和更新緩存的順序一致，那就會出現數據庫中和緩存中數據不一致的情況。所以一般來說考慮刪除緩存。

• 先刪除緩存，再更新數據庫；

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

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

1）先更新數據庫，再刪除緩存（注：更推薦使用這種策略）。

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

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

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

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

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

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

八、總結

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

九、參考資料

1、《大型網站技術架構：核心原理與案例分析》

2、你應該知道的緩存進化史

3、如何優雅的設計和使用緩存？

4、理解分布式系統中的緩存架構(上)

5、緩存那些事

6、分布式之數據庫和緩存雙寫一致性方案解析

作者：vivo互聯網服務器團隊-Zhang Peng