万字多图：搞懂分布式系统缓存设计
文章來(lái)源：【vivo互聯(lián)網(wǎng)服務(wù)器團(tuán)隊(duì)】
目錄
緩存簡(jiǎn)介
緩存的分類
進(jìn)程內(nèi)緩存
分布式緩存
多級(jí)緩存
緩存問(wèn)題
緩存策略
總結(jié)
緩存簡(jiǎn)介
| 什么是緩存
緩存就是數(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ù)更快訪問(wèn)相應(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ù)
| 何時(shí)需要緩存
引入緩存，會(huì)增加系統(tǒng)的復(fù)雜度。所以，引入緩存前，需要先權(quán)衡是否值得，考量點(diǎn)如下：
CPU 開(kāi)銷：如果應(yīng)用某個(gè)計(jì)算需要消耗大量 CPU，可以考慮緩存其計(jì)算結(jié)果。典型場(chǎng)景：復(fù)雜的、頻繁調(diào)用的正則計(jì)算；分布式計(jì)算中間狀態(tài)等。
IO 開(kāi)銷：如果數(shù)據(jù)庫(kù)連接池比較繁忙，可以考慮緩存其查詢結(jié)果。
在數(shù)據(jù)層引入緩存，有以下幾個(gè)好處：
提升數(shù)據(jù)讀取速度。
提升系統(tǒng)擴(kuò)展能力，通過(guò)擴(kuò)展緩存，提升系統(tǒng)承載能力。
降低存儲(chǔ)成本，Cache+DB 的方式可以承擔(dān)原有需要多臺(tái) DB 才能承擔(dān)的請(qǐng)求量，節(jié)省機(jī)器成本。
| 緩存的基本原理
根據(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í)性。
| 緩存淘汰策略
緩存淘汰的類型：
基于空間：設(shè)置緩存空間大小。
基于容量：設(shè)置緩存存儲(chǔ)記錄數(shù)。
基于時(shí)間：TTL（Time To Live，即存活期）緩存數(shù)據(jù)從創(chuàng)建到過(guò)期的時(shí)間；TTI（Time To Idle，即空閑期）緩存數(shù)據(jù)多久沒(méi)被訪問(wèn)的時(shí)間。
緩存淘汰算法如下：
1）FIFO：先進(jìn)先出。在這種淘汰算法中，先進(jìn)入緩存的會(huì)先被淘汰。這種可謂是最簡(jiǎn)單的了，但是會(huì)導(dǎo)致我們命中率很低。
試想一下我們?nèi)绻袀€(gè)訪問(wèn)頻率很高的數(shù)據(jù)是所有數(shù)據(jù)第一個(gè)訪問(wèn)的，而那些不是很高的是后面再訪問(wèn)的，那這樣就會(huì)把我們的首個(gè)數(shù)據(jù)但是他的訪問(wèn)頻率很高給擠出。
2）LRU：最近最少使用算法。在這種算法中避免了上面的問(wèn)題，每次訪問(wèn)數(shù)據(jù)都會(huì)將其放在我們的隊(duì)尾，如果需要淘汰數(shù)據(jù)，就只需要淘汰隊(duì)首即可。
但是這個(gè)依然有個(gè)問(wèn)題，如果有個(gè)數(shù)據(jù)在 1 個(gè)小時(shí)的前 59 分鐘訪問(wèn)了 1 萬(wàn)次（可見(jiàn)這是個(gè)熱點(diǎn)數(shù)據(jù)），再后一分鐘沒(méi)有訪問(wèn)這個(gè)數(shù)據(jù)，但是有其他的數(shù)據(jù)訪問(wèn)，就導(dǎo)致了我們這個(gè)熱點(diǎn)數(shù)據(jù)被淘汰。
3）LFU：最近最少頻率使用。在這種算法中又對(duì)上面進(jìn)行了優(yōu)化，利用額外的空間記錄每個(gè)數(shù)據(jù)的使用頻率，然后選出頻率最低進(jìn)行淘汰。這樣就避免了 LRU 不能處理時(shí)間段的問(wèn)題。
這三種緩存淘汰算法，實(shí)現(xiàn)復(fù)雜度一個(gè)比一個(gè)高，同樣的命中率也是一個(gè)比一個(gè)好。而我們一般來(lái)說(shuō)選擇的方案居中即可，即實(shí)現(xiàn)成本不是太高，而命中率也還行的 LRU。
緩存的分類
緩存從部署角度，可以分為客戶端緩存和服務(wù)端緩存。
客戶端緩存：
HTTP 緩存
瀏覽器緩存
APP 緩存（Android、iOS）
服務(wù)端緩存：
CDN 緩存：存放 HTML、CSS、JS 等靜態(tài)資源。
反向代理緩存：動(dòng)靜分離，只緩存用戶請(qǐng)求的靜態(tài)資源。
數(shù)據(jù)庫(kù)緩存：數(shù)據(jù)庫(kù)（如 MySQL）自身一般也有緩存，但因?yàn)槊新屎透骂l率問(wèn)題，不推薦使用。
進(jìn)程內(nèi)緩存：緩存應(yīng)用字典等常用數(shù)據(jù)。
分布式緩存：緩存數(shù)據(jù)庫(kù)中的熱點(diǎn)數(shù)據(jù)。
其中，CDN 緩存、反向代理緩存、數(shù)據(jù)庫(kù)緩存一般由專職人員維護(hù)（運(yùn)維、DBA）。后端開(kāi)發(fā)一般聚焦于進(jìn)程內(nèi)緩存、分布式緩存。
| HTTP 緩存
| CDN 緩存
CDN 將數(shù)據(jù)緩存到離用戶物理距離最近的服務(wù)器，使得用戶可以就近獲取請(qǐng)求內(nèi)容。CDN 一般緩存靜態(tài)資源文件（頁(yè)面，腳本，圖片，視頻，文件等）。
國(guó)內(nèi)網(wǎng)絡(luò)異常復(fù)雜，跨運(yùn)營(yíng)商的網(wǎng)絡(luò)訪問(wèn)會(huì)很慢。為了解決跨運(yùn)營(yíng)商或各地用戶訪問(wèn)問(wèn)題，可以在重要的城市，部署 CDN 應(yīng)用。
使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問(wèn)響應(yīng)速度和命中率。
圖片引用自：Why use a CDN
①CDN 原理
CDN 的基本原理是廣泛采用各種緩存服務(wù)器，將這些緩存服務(wù)器分布到用戶訪問(wèn)相對(duì)集中的地區(qū)或網(wǎng)絡(luò)中，在用戶訪問(wèn)網(wǎng)站時(shí)，利用全局負(fù)載技術(shù)將用戶的訪問(wèn)指向距離最近的工作正常的緩存服務(wù)器上，由緩存服務(wù)器直接響應(yīng)用戶請(qǐng)求。
未部署 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)過(guò) 3 個(gè)節(jié)點(diǎn)，6 個(gè)步驟完成一次用戶訪問(wèn)操作。
部署 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)過(guò) 2 個(gè)節(jié)點(diǎn)，2 個(gè)步驟完成一次用戶訪問(wèn)操作。
與不部署 CDN 服務(wù)相比，減少了 1 個(gè)節(jié)點(diǎn)，4 個(gè)步驟的訪問(wèn)。極大的提高了系統(tǒng)的響應(yīng)速度。
②CDN 特點(diǎn)
優(yōu)點(diǎn)：
本地 Cache 加速：提升訪問(wèn)速度，尤其含有大量圖片和靜態(tài)頁(yè)面站點(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ò)中的用戶都能得到良好的訪問(wèn)質(zhì)量；
遠(yuǎn)程加速：遠(yuǎn)程訪問(wèn)用戶根據(jù) DNS 負(fù)載均衡技術(shù)智能自動(dòng)選擇 Cache 服務(wù)器，選擇最快的 Cache 服務(wù)器，加快遠(yuǎn)程訪問(wèn)的速度；
帶寬優(yōu)化：自動(dòng)生成服務(wù)器的遠(yuǎn)程 Mirror（鏡像）cache 服務(wù)器，遠(yuǎn)程用戶訪問(wèn)時(shí)從 cache 服務(wù)器上讀取數(shù)據(jù)，減少遠(yuǎn)程訪問(wè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ù)的一致性問(wèn)題，解決方案（主要是在性能和數(shù)據(jù)一致性二者間尋找一個(gè)平衡）；設(shè)置緩存失效時(shí)間（1 個(gè)小時(shí)，過(guò)期后同步數(shù)據(jù)）；針對(duì)資源設(shè)置版本號(hào)。
| 反向代理緩存
反向代理（Reverse Proxy）方式是指以代理服務(wù)器來(lái)接受 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ù)器。
①反向代理緩存原理
反向代理位于應(yīng)用服務(wù)器同一網(wǎng)絡(luò)，處理所有對(duì) WEB 服務(wù)器的請(qǐng)求。
反向代理緩存的原理：
如果用戶請(qǐng)求的頁(yè)面在代理服務(wù)器上有緩存的話，代理服務(wù)器直接將緩存內(nèi)容發(fā)送給用戶。
如果沒(méi)有緩存則先向 WEB 服務(wù)器發(fā)出請(qǐng)求，取回?cái)?shù)據(jù)，本地緩存后再發(fā)送給用戶。
這種方式通過(guò)降低向 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。
②反向代理緩存比較
常用的代理緩存有 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ò)傳輸消耗，比通過(guò)網(wǎng)絡(luò)讀取數(shù)據(jù)庫(kù)速度更快。可以應(yīng)用在對(duì)速度要求不是很高，但需要大量緩存存儲(chǔ)的場(chǎng)景。
內(nèi)存緩存：直接將數(shù)據(jù)存儲(chǔ)到本機(jī)內(nèi)存中，通過(guò)程序直接維護(hù)緩存對(duì)象，是訪問(wèn)速度最快的方式。
常見(jiàn)的本地緩存實(shí)現(xiàn)方案：HashMap、Guava Cache、Caffeine、Ehcache。
| ConcurrentHashMap
最簡(jiǎn)單的進(jìn)程內(nèi)緩存可以通過(guò) JDK 自帶的 HashMap 或 ConcurrentHashMap 實(shí)現(xiàn)。
適用場(chǎng)景：不需要淘汰的緩存數(shù)據(jù)。
缺點(diǎn)：無(wú)法進(jìn)行緩存淘汰，內(nèi)存會(huì)無(wú)限制的增長(zhǎng)。
| LRUHashMap
可以通過(guò)繼承 LinkedHashMap 來(lái)實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 LRUHashMap。重寫 removeEldestEntry 方法，即可完成一個(gè)簡(jiǎn)單的最近最少使用算法。
缺點(diǎn)：
鎖競(jìng)爭(zhēng)嚴(yán)重，性能比較低。
不支持過(guò)期時(shí)間。
不支持自動(dòng)刷新。
| Guava Cache
解決了LRUHashMap 中的幾個(gè)缺點(diǎn)。Guava Cache 采用了類似 ConcurrentHashMap 的思想，分段加鎖，減少鎖競(jìng)爭(zhēng)。
Guava Cache 對(duì)于過(guò)期的 Entry 并沒(méi)有馬上過(guò)期（也就是并沒(méi)有后臺(tái)線程一直在掃），而是通過(guò)進(jìn)行讀寫操作的時(shí)候進(jìn)行過(guò)期處理，這樣做的好處是避免后臺(tái)線程掃描的時(shí)候進(jìn)行全局加鎖。直接通過(guò)查詢，判斷其是否滿足刷新條件，進(jìn)行刷新。
| Caffeine
Caffeine 實(shí)現(xiàn)了 W-TinyLFU（LFU + LRU 算法的變種），其命中率和讀寫吞吐量大大優(yōu)于 Guava Cache，其實(shí)現(xiàn)原理較復(fù)雜。
| 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)存和磁盤，因此無(wú)需擔(dān)心容量問(wèn)題；
緩存數(shù)據(jù)會(huì)在虛擬機(jī)重啟的過(guò)程中寫入磁盤；
可以通過(guò) RMI、可插入 API 等方式進(jìn)行分布式緩存；
具有緩存和緩存管理器的偵聽(tīng)接口；
支持多緩存管理器實(shí)例，以及一個(gè)實(shí)例的多個(gè)緩存區(qū)域；
提供 Hibernate 的緩存實(shí)現(xiàn)。
缺點(diǎn)：
使用磁盤 Cache 的時(shí)候非常占用磁盤空間；
不保證數(shù)據(jù)的安全；
雖然支持分布式緩存，但效率不高（通過(guò)組播方式，在不同節(jié)點(diǎn)之間同步數(shù)據(jù)）。
| 進(jìn)程內(nèi)緩存對(duì)比
常用進(jìn)程內(nèi)緩存技術(shù)對(duì)比如上圖：
ConcurrentHashMap：比較適合緩存比較固定不變的元素，且緩存的數(shù)量較小的。雖然從上面表格中比起來(lái)有點(diǎn)遜色，但是其由于是 JDK 自帶的類，在各種框架中依然有大量的使用，比如我們可以用來(lái)緩存我們反射的 Method，Field 等等；也可以緩存一些鏈接，防止其重復(fù)建立。在 Caffeine 中也是使用的 ConcurrentHashMap 來(lái)存儲(chǔ)元素。
LRUMap：如果不想引入第三方包，又想使用淘汰算法淘汰數(shù)據(jù)，可以使用這個(gè)。
Ehcache：由于其 jar 包很大，較重量級(jí)。對(duì)于需要持久化和集群的一些功能的，可以選擇 Ehcache。需要注意的是，雖然 Ehcache 也支持分布式緩存，但是由于其節(jié)點(diǎn)間通信方式為 rmi，表現(xiàn)不如 Redis，所以一般不建議用它來(lái)作為分布式緩存。
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，取得過(guò)不錯(cuò)的效果。
總結(jié)一下：如果不需要淘汰算法則選擇 ConcurrentHashMap，如果需要淘汰算法和一些豐富的 API，推薦選擇。
分布式緩存
分布式緩存解決了進(jìn)程內(nèi)緩存最大的問(wèn)題：如果應(yīng)用是分布式系統(tǒng)，節(jié)點(diǎn)之間無(wú)法共享彼此的進(jìn)程內(nèi)緩存。
分布式緩存的應(yīng)用場(chǎng)景：
緩存經(jīng)過(guò)復(fù)雜計(jì)算得到的數(shù)據(jù)。
緩存系統(tǒng)中頻繁訪問(wèn)的熱點(diǎn)數(shù)據(jù)，減輕數(shù)據(jù)庫(kù)壓力。
不同分布式緩存的實(shí)現(xiàn)原理往往有比較大的差異。本文主要針對(duì) Memcached 和 Redis 進(jìn)行說(shuō)明。
| Memcached
Memcached 是一個(gè)高性能，分布式內(nèi)存對(duì)象緩存系統(tǒng)，通過(guò)在內(nèi)存里維護(hù)一個(gè)統(tǒng)一的巨大的 Hash 表，它能夠用來(lái)存儲(chǔ)各種格式的數(shù)據(jù)，包括圖像、視頻、文件以及數(shù)據(jù)庫(kù)檢索的結(jié)果等。
簡(jiǎn)單的說(shuō)就是：將數(shù)據(jù)緩存到內(nèi)存中，然后從內(nèi)存中讀取，從而大大提高讀取速度。
Memcached 特性：
使用物理內(nèi)存作為緩存區(qū)，可獨(dú)立運(yùn)行在服務(wù)器上。每個(gè)進(jìn)程最大 2G，如果想緩存更多的數(shù)據(jù)，可以開(kāi)辟更多的 Memcached 進(jìn)程（不同端口）或者使用分布式 Memcached 進(jìn)行緩存，將數(shù)據(jù)緩存到不同的物理機(jī)或者虛擬機(jī)上。
使用 key-value 的方式來(lái)存儲(chǔ)數(shù)據(jù)。這是一種單索引的結(jié)構(gòu)化數(shù)據(jù)組織形式，可使數(shù)據(jù)項(xiàng)查詢時(shí)間復(fù)雜度為 O(1)。
協(xié)議簡(jiǎn)單，基于文本行的協(xié)議。直接通過(guò) telnet 在 Memcached 服務(wù)器上可進(jìn)行存取數(shù)據(jù)操作，簡(jiǎn)單，方便多種緩存參考此協(xié)議。
基于 libevent 高性能通信。Libevent 是一套利用 C 開(kāi)發(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ì)是否過(guò)期，而是在獲取 key 值時(shí)查看記錄的時(shí)間戳，檢查 key/value 對(duì)空間是否過(guò)期，這樣可減輕服務(wù)器的負(fù)載。
內(nèi)置了一套高效的內(nèi)存管理算法。這套內(nèi)存管理效率很高，而且不會(huì)造成內(nèi)存碎片，但是它最大的缺點(diǎn)就是會(huì)導(dǎo)致空間浪費(fèi)。當(dāng)內(nèi)存滿后，通過(guò) LRU 算法自動(dòng)刪除不使用的緩存。
不支持持久化。Memcached 沒(méi)有考慮數(shù)據(jù)的容災(zāi)問(wèn)題，重啟服務(wù)，所有數(shù)據(jù)會(huì)丟失。
Memcached 工作原理如下：
①內(nèi)存管理
Memcached 利用 slab allocation 機(jī)制來(lái)分配和管理內(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)。
②緩存淘汰策略
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ì)是否過(guò)期，而是在獲取 key 值時(shí)查看記錄的時(shí)間戳，檢查 key/value 對(duì)空間是否過(guò)期，這樣可減輕服務(wù)器的負(fù)載。
③分區(qū)
Memcached 服務(wù)器之間彼此不通信，它的分布式能力是依賴客戶端來(lái)實(shí)現(xiàn)。具體來(lái)說(shuō)，就是在客戶端實(shí)現(xiàn)一種算法，根據(jù) key 來(lái)計(jì)算出數(shù)據(jù)應(yīng)該向哪個(gè)服務(wù)器節(jié)點(diǎn)讀/寫。
而這種選取集群節(jié)點(diǎn)的算法常見(jiàn)的有三種：
哈希取余算法：使用公式：Hash（key）% N 計(jì)算出哈希值來(lái)決定數(shù)據(jù)映射到哪一個(gè)節(jié)點(diǎn)。
一致性哈希算法：可以很好的解決 穩(wě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ù)量的槽。
| Redis
Redis 是一個(gè)開(kāi)源（BSD 許可）的，基于內(nèi)存的，多數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)系統(tǒng)。可以用作數(shù)據(jù)庫(kù)、緩存和消息中間件。
Redis 還可以使用客戶端分片來(lái)擴(kuò)展寫性能。內(nèi)置了 復(fù)制（replication），LUA 腳本（Lua scripting），LRU 驅(qū)動(dòng)事件（LRU eviction），事務(wù)（transactions） 和不同級(jí)別的 磁盤持久化（persistence）， 并通過(guò) Redis 哨兵（Sentinel）和自動(dòng)分區(qū)（Cluster）提供高可用性（high availability）。
Redis 特性如下：
①支持多種數(shù)據(jù)類型 - string、Hash、list、set、sorted set。
②支持多種數(shù)據(jù)淘汰策略：
volatile-lru：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選最近最少使用的數(shù)據(jù)淘汰；
volatile-ttl：從已設(shè)置過(guò)期時(shí)間的數(shù)據(jù)集中挑選將要過(guò)期的數(shù)據(jù)淘汰；
volatile-random：從已設(shè)置過(guò)期時(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。
④通過(guò) Redis cluster 提供集群模式。
Redis 原理如下：
Redis 有兩種數(shù)據(jù)淘汰實(shí)現(xiàn)：
消極方式：訪問(wèn) Redis key 時(shí)，如果發(fā)現(xiàn)它已經(jīng)失效，則刪除它。
積極方式：周期性從設(shè)置了失效時(shí)間的 key 中，根據(jù)淘汰策略，選擇一部分失效的 key 進(jìn)行刪除。
分區(qū)：
Redis Cluster 集群包含 16384 個(gè)虛擬 Hash 槽，它通過(guò)一個(gè)高效的算法來(lái)計(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)。
主從復(fù)制：
Redis 2.8 后支持異步復(fù)制。它有兩種模式：完整重同步（full resychronization） - 用于初次復(fù)制。執(zhí)行步驟與 SYNC 命令基本一致。部分重同步（partial resychronization） - 用于斷線后重復(fù)制。如果條件允許，主服務(wù)器可以將主從服務(wù)器連接斷開(kāi)期間執(zhí)行的寫命令發(fā)送給從服務(wù)器，從服務(wù)器只需接收并執(zhí)行這些寫命令，即可將主從服務(wù)器的數(shù)據(jù)庫(kù)狀態(tài)保持一致。
集群中每個(gè)節(jié)點(diǎn)都會(huì)定期向集群中的其他節(jié)點(diǎn)發(fā)送 PING 消息，以此來(lái)檢測(cè)對(duì)方是否在線。
如果一個(gè)主節(jié)點(diǎn)被認(rèn)為下線，則在其從節(jié)點(diǎn)中，根據(jù) Raft 算法，選舉出一個(gè)節(jié)點(diǎn)，升級(jí)為主節(jié)點(diǎn)。
數(shù)據(jù)一致性：
Redis 不保證強(qiáng)一致性，因?yàn)檫@會(huì)使得集群性能大大降低。
Redis 是通過(guò)異步復(fù)制來(lái)實(shí)現(xiàn)最終一致性。
| 分布式緩存對(duì)比
不同的分布式緩存功能特性和實(shí)現(xiàn)原理方面有很大的差異，因此他們所適應(yīng)的場(chǎng)景也有所不同。
這里選取三個(gè)比較出名的分布式緩存（MemCache，Redis，Tair）來(lái)作為比較。
如上圖：
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)，讀寫性能較高，部分類型比較慢，理論上容量可以無(wú)限擴(kuò)充。
總結(jié)：如果服務(wù)對(duì)延遲比較敏感，Map/Set 數(shù)據(jù)也比較多的話，比較適合 Redis。如果服務(wù)需要放入緩存量的數(shù)據(jù)很大，對(duì)延遲又不是特別敏感的話，那就可以選擇 Memcached。
多級(jí)緩存
| 整體緩存框架
通常，一個(gè)大型軟件系統(tǒng)的緩存采用多級(jí)緩存方案：
請(qǐng)求過(guò)程：
瀏覽器向客戶端發(fā)起請(qǐng)求，如果 CDN 有緩存則直接返回；
如果 CDN 無(wú)緩存，則訪問(wèn)反向代理服務(wù)器；
如果反向代理服務(wù)器有緩存則直接返回；
如果反向代理服務(wù)器無(wú)緩存或動(dòng)態(tài)請(qǐng)求，則訪問(wèn)應(yīng)用服務(wù)器；
應(yīng)用服務(wù)器訪問(wèn)進(jìn)程內(nèi)緩存；如果有緩存，則返回代理服務(wù)器，并緩存數(shù)據(jù)（動(dòng)態(tài)請(qǐng)求不緩存）；
如果進(jìn)程內(nèi)緩存無(wú)數(shù)據(jù)，則讀取分布式緩存；并返回應(yīng)用服務(wù)器；應(yīng)用服務(wù)器將數(shù)據(jù)緩存到本地緩存（部分）；
如果分布式緩存無(wú)數(shù)據(jù)，則應(yīng)用程序讀取數(shù)據(jù)庫(kù)數(shù)據(jù)，并放入分布式緩存；
| 使用進(jìn)程內(nèi)緩存
如果應(yīng)用服務(wù)是單點(diǎn)應(yīng)用，那么進(jìn)程內(nèi)緩存當(dāng)然是緩存的首選方案。
對(duì)于進(jìn)程內(nèi)緩存，其本來(lái)受限于內(nèi)存的大小的限制，以及進(jìn)程緩存更新后其他緩存無(wú)法得知。
所以一般來(lái)說(shuō)進(jìn)程緩存適用于：
數(shù)據(jù)量不是很大且更新頻率較低的數(shù)據(jù)。
如果更新頻繁的數(shù)據(jù)，也想使用進(jìn)程內(nèi)緩存，那么可以將其過(guò)期時(shí)間設(shè)置為較短的時(shí)間，或者設(shè)置較短的自動(dòng)刷新時(shí)間。
這種方案存在以下問(wèn)題：
如果應(yīng)用服務(wù)是分布式系統(tǒng)，應(yīng)用節(jié)點(diǎn)之間無(wú)法共享緩存，存在數(shù)據(jù)不一致問(wèn)題。
由于進(jìn)程內(nèi)緩存受限于內(nèi)存大小的限制，所以緩存不能無(wú)限擴(kuò)展。
| 使用分布式緩存
如果應(yīng)用服務(wù)是分布式系統(tǒng)，那么最簡(jiǎn)單的緩存方案就是直接使用分布式緩存。
其應(yīng)用場(chǎng)景如圖所示：
Redis 用來(lái)存儲(chǔ)熱點(diǎn)數(shù)據(jù)，如果緩存不命中，則去查詢數(shù)據(jù)庫(kù)，并更新緩存。
這種方案存在以下問(wèn)題：
緩存服務(wù)如果掛了，這時(shí)應(yīng)用只能訪問(wèn)數(shù)據(jù)庫(kù)，容易造成緩存雪崩。
訪問(wèn)分布式緩存服務(wù)會(huì)有一定的 I/O 以及序列化反序列化的開(kāi)銷，雖然性能很高，但是其終究沒(méi)有在內(nèi)存中查詢快。
| 使用多級(jí)緩存
單純使用進(jìn)程內(nèi)緩存和分布式緩存都存在各自的不足。如果需要更高的性能以及更好的可用性，我們可以將緩存設(shè)計(jì)為多級(jí)結(jié)構(gòu)。將最熱的數(shù)據(jù)使用進(jìn)程內(nèi)緩存存儲(chǔ)在內(nèi)存中，進(jìn)一步提升訪問(wèn)速度。
這個(gè)設(shè)計(jì)思路在計(jì)算機(jī)系統(tǒng)中也存在，比如 CPU 使用 L1、L2、L3 多級(jí)緩存，用來(lái)減少對(duì)內(nèi)存的直接訪問(wèn)，從而加快訪問(wèn)速度。
一般來(lái)說(shuō)，多級(jí)緩存架構(gòu)使用二級(jí)緩存已可以滿足大部分業(yè)務(wù)需求，過(guò)多的分級(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í)緩存。
多級(jí)緩存查詢：
多級(jí)緩存查詢流程如下：
首先，查詢 L1 緩存，如果緩存命中，直接返回結(jié)果；如果沒(méi)有命中，執(zhí)行下一步。
接下來(lái)，查詢 L2 緩存，如果緩存命中，直接返回結(jié)果并回填 L1 緩存；如果沒(méi)有命中，執(zhí)行下一步。
最后，查詢數(shù)據(jù)庫(kù)，返回結(jié)果并依次回填 L2 緩存、L1 緩存。
多級(jí)緩存更新：對(duì)于 L1 緩存，如果有數(shù)據(jù)更新，只能刪除并更新所在機(jī)器上的緩存，其他機(jī)器只能通過(guò)超時(shí)機(jī)制來(lái)刷新緩存。
超時(shí)設(shè)定可以有兩種策略：
設(shè)置成寫入后多少時(shí)間后過(guò)期
設(shè)置成寫入后多少時(shí)間刷新
對(duì)于 L2 緩存，如果有數(shù)據(jù)更新，其他機(jī)器立馬可見(jiàn)。但是，也必須要設(shè)置超時(shí)時(shí)間，其時(shí)間應(yīng)該比 L1 緩存的有效時(shí)間長(zhǎng)。為了解決進(jìn)程內(nèi)緩存不一致的問(wèn)題，設(shè)計(jì)可以進(jìn)一步優(yōu)化。
通過(guò)消息隊(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)緩存過(guò)期，刷新緩存時(shí)，也能保證數(shù)據(jù)的最終一致性。
緩存問(wèn)題
| 緩存雪崩
緩存雪崩是指緩存不可用或者大量緩存由于超時(shí)時(shí)間相同在同一時(shí)間段失效，大量請(qǐng)求直接訪問(wèn)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)壓力過(guò)大導(dǎo)致系統(tǒng)雪崩。
舉例來(lái)說(shuō)，對(duì)于系統(tǒng) A，假設(shè)每天高峰期每秒 5000 個(gè)請(qǐng)求，本來(lái)緩存在高峰期可以扛住每秒 4000 個(gè)請(qǐng)求，但是緩存機(jī)器意外發(fā)生了全盤宕機(jī)。
緩存掛了，此時(shí) 1 秒 5000 個(gè)請(qǐng)求全部落數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)必然扛不住，它會(huì)報(bào)一下警，然后就掛了。
此時(shí)，如果沒(méi)有采用什么特別的方案來(lái)處理這個(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)單來(lái)說(shuō)，就是多級(jí)緩存方案。系統(tǒng)收到一個(gè)查詢請(qǐng)求，先查本地緩存，再查分布式緩存，最后查數(shù)據(jù)庫(kù)，只要命中，立即返回。
解決緩存雪崩的輔助手段如下：
監(jiān)控緩存，彈性擴(kuò)容。
緩存的過(guò)期時(shí)間可以取個(gè)隨機(jī)值。這么做是為避免緩存同時(shí)失效，使得數(shù)據(jù)庫(kù) IO 驟升。比如：以前是設(shè)置 10 分鐘的超時(shí)時(shí)間，那每個(gè) Key 都可以隨機(jī) 8-13 分鐘過(guò)期，盡量讓不同 Key 的過(guò)期時(shí)間不同。
| 緩存穿透
緩存穿透是指：查詢的數(shù)據(jù)在數(shù)據(jù)庫(kù)中不存在，那么緩存中自然也不存在。所以，應(yīng)用在緩存中查不到，則會(huì)去查詢數(shù)據(jù)庫(kù)。當(dāng)這樣的請(qǐng)求多了后，數(shù)據(jù)庫(kù)的壓力就會(huì)增大。
解決緩存穿透，一般有兩種方法：
①緩存空值
對(duì)于返回為 NULL 的依然緩存，對(duì)于拋出異常的返回不進(jìn)行緩存。
采用這種手段的會(huì)增加我們緩存的維護(hù)成本，需要在插入緩存的時(shí)候刪除這個(gè)空緩存，當(dāng)然我們可以通過(guò)設(shè)置較短的超時(shí)時(shí)間來(lái)解決這個(gè)問(wèn)題。
②過(guò)濾不可能存在的數(shù)據(jù)
如下圖：
制定一些規(guī)則過(guò)濾一些不可能存在的數(shù)據(jù)。可以使用布隆過(guò)濾器（針對(duì)二進(jìn)制操作的數(shù)據(jù)結(jié)構(gòu)，所以性能高），比如你的訂單 ID 明顯是在一個(gè)范圍 1-1000，如果不是 1-1000 之內(nèi)的數(shù)據(jù)那其實(shí)可以直接給過(guò)濾掉。
針對(duì)于一些惡意攻擊，攻擊帶過(guò)來(lái)的大量 key 是不存在的，那么我們采用第一種方案就會(huì)緩存大量不存在 key 的數(shù)據(jù)。
此時(shí)我們采用第一種方案就不合適了，我們完全可以先對(duì)使用第二種方案進(jìn)行過(guò)濾掉這些 key。
針對(duì)這種 key 異常多、請(qǐng)求重復(fù)率比較低的數(shù)據(jù)，我們就沒(méi)有必要進(jìn)行緩存，使用第二種方案直接過(guò)濾掉。
而對(duì)于空數(shù)據(jù)的 key 有限的，重復(fù)率比較高的，我們則可以采用第一種方式進(jìn)行緩存。
| 緩存擊穿
緩存擊穿是指，熱點(diǎn)數(shù)據(jù)失效瞬間，大量請(qǐng)求直接訪問(wèn)數(shù)據(jù)庫(kù)。例如，某些 key 是熱點(diǎn)數(shù)據(jù)，訪問(wèn)非常頻繁。如果某個(gè) key 失效的瞬間，大量的請(qǐng)求過(guò)來(lái)，緩存未命中，然后去數(shù)據(jù)庫(kù)訪問(wèn)，此時(shí)數(shù)據(jù)庫(kù)訪問(wèn)量會(huì)急劇增加。
為了避免這個(gè)問(wèn)題，我們可以采取下面的兩個(gè)手段：
分布式鎖：鎖住熱點(diǎn)數(shù)據(jù)的 key，避免大量線程同時(shí)訪問(wèn)同一個(gè) key。
定時(shí)異步刷新：可以對(duì)部分?jǐn)?shù)據(jù)采取失效前自動(dòng)刷新的策略，而不是到期自動(dòng)淘汰。淘汰其實(shí)也是為了數(shù)據(jù)的時(shí)效性，所以采用自動(dòng)刷新也可以。
小結(jié)：上面逐一介紹了緩存使用中常見(jiàn)的問(wèn)題。這里，從發(fā)生時(shí)間段的角度整體歸納一下緩存問(wèn)題解決方案。
事前：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 做分布式緩存。
緩存策略
| 緩存預(yù)熱
緩存預(yù)熱是指系統(tǒng)啟動(dòng)后，直接查詢熱點(diǎn)數(shù)據(jù)并緩存。這樣就可以避免用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫(kù)，然后再更新緩存的問(wèn)題。
解決方案：
手動(dòng)刷新緩存：直接寫個(gè)緩存刷新頁(yè)面，上線時(shí)手工操作下。
應(yīng)用啟動(dòng)時(shí)刷新緩存：數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載。
定時(shí)異步刷新緩存。
| 如何緩存
不過(guò)期緩存：
緩存更新模式
開(kāi)啟事務(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ì)于上面的問(wèn)題，影響較小。
過(guò)期緩存：采用懶加載。對(duì)于熱點(diǎn)數(shù)據(jù)，可以設(shè)置較短的緩存時(shí)間，并定期異步加載。
| 緩存更新
一般來(lái)說(shuō)，系統(tǒng)如果不是嚴(yán)格要求緩存和數(shù)據(jù)庫(kù)保持一致性的話，盡量不要將讀請(qǐng)求和寫請(qǐng)求串行化。串行化可以保證一定不會(huì)出現(xiàn)數(shù)據(jù)不一致的情況，但是它會(huì)導(dǎo)致系統(tǒng)的吞吐量大幅度下降。
一般來(lái)說(shuō)緩存的更新有兩種情況：
先刪除緩存，再更新數(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ù)不一致的情況。所以一般來(lái)說(shuō)考慮刪除緩存。
對(duì)于一個(gè)更新操作簡(jiǎn)單來(lái)說(shuō)，就是先去各級(jí)緩存進(jìn)行刪除，然后更新數(shù)據(jù)庫(kù)。
這個(gè)操作有一個(gè)比較大的問(wèn)題，在對(duì)緩存刪除完之后，有一個(gè)讀請(qǐng)求，這個(gè)時(shí)候由于緩存被刪除所以直接會(huì)讀庫(kù)，讀操作的數(shù)據(jù)是老的并且會(huì)被加載進(jìn)入緩存當(dāng)中，后續(xù)讀請(qǐng)求全部訪問(wèn)的老數(shù)據(jù)。
對(duì)緩存的操作不論成功失敗都不能阻塞我們對(duì)數(shù)據(jù)庫(kù)的操作，那么很多時(shí)候刪除緩存可以用異步的操作，但是先刪除緩存不能很好的適用于這個(gè)場(chǎng)景。
先刪除緩存也有一個(gè)好處是，如果對(duì)數(shù)據(jù)庫(kù)操作失敗了，那么由于先刪除的緩存，最多只是造成 Cache Miss。
①先更新數(shù)據(jù)庫(kù)，再刪除緩存（注：更推薦使用這種策略）。
如果我們使用更新數(shù)據(jù)庫(kù)，再刪除緩存就能避免上面的問(wèn)題。
但是同樣的引入了新的問(wèn)題：假設(shè)執(zhí)行更新操作時(shí)，又接收到查詢請(qǐng)求，此時(shí)就會(huì)返回緩存中的老數(shù)據(jù)。更麻煩的是，如果數(shù)據(jù)庫(kù)更新操作執(zhí)行失敗，則緩存中可能永遠(yuǎn)是臟數(shù)據(jù)。
②應(yīng)該選擇哪種更新策略
通過(guò)上面的內(nèi)容，我們知道，兩種更新策略都存在并發(fā)問(wèn)題。
但是建議選擇先更新數(shù)據(jù)庫(kù)，再刪除緩存，因?yàn)槠洳l(fā)問(wèn)題出現(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)一致性，則可以通過(guò) 2PC 或 Paxos 協(xié)議來(lái)實(shí)現(xiàn)。但是 2PC 太慢，而 Paxos 太復(fù)雜，所以如果不是非常重要的數(shù)據(jù)，不建議使用強(qiáng)一致性方案。
總結(jié)
最后，通過(guò)一張思維導(dǎo)圖來(lái)總結(jié)一下本文所述的知識(shí)點(diǎn)，幫助大家對(duì)緩存有一個(gè)系統(tǒng)性的認(rèn)識(shí)。
-------------? END??-------------
掃碼免費(fèi)獲取600+頁(yè)石杉老師原創(chuàng)精品文章匯總PDF
原創(chuàng)技術(shù)文章匯總
點(diǎn)個(gè)在看你最好看
總結(jié)
以上是生活随笔為你收集整理的万字多图：搞懂分布式系统缓存设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 武汉python自动化测试招聘,pyth
- 下一篇： 射频卡的使用