一谎亩、緩存簡(jiǎn)介

1.1 什么是緩存

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

• 將數(shù)據(jù)寫(xiě)入/讀取速度更快的存儲(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, 磁盤(pán) cache 等烫扼。本文中提及到緩存主要是指互聯(lián)網(wǎng)應(yīng)用中所使用的緩存組件曙求。緩存命中率是緩存的重要度量指標(biāo)，命中率越高越好映企。

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

1.2 何時(shí)需要緩存

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

• CPU 開(kāi)銷(xiāo)：如果應(yīng)用某個(gè)計(jì)算需要消耗大量 CPU双絮，可以考慮緩存其計(jì)算結(jié)果浴麻。典型場(chǎng)景：復(fù)雜的、頻繁調(diào)用的正則計(jì)算囤攀；分布式計(jì)算中間狀態(tài)等软免。
• IO 開(kāi)銷(xiāo)：如果數(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ī)器成本孤个。

1.3 緩存的基本原理

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

• 懶漢式(讀時(shí)觸發(fā))：先查詢 DB 里的數(shù)據(jù), 然后把相關(guān)的數(shù)據(jù)寫(xiě)入 Cache沛简。
• 饑餓式(寫(xiě)時(shí)觸發(fā))：寫(xiě)入 DB 后, 然后把相關(guān)的數(shù)據(jù)也寫(xiě)入 Cache齐鲤。
• 定期刷新：適合周期性的跑數(shù)據(jù)的任務(wù)，或者列表型的數(shù)據(jù)覆享，而且不要求絕對(duì)實(shí)時(shí)性佳遂。

1.4 緩存淘汰策略

1.4.1 緩存淘汰的類(lèi)型

1、基于空間：設(shè)置緩存空間大小撒顿。
2丑罪、基于容量：設(shè)置緩存存儲(chǔ)記錄數(shù)。
3凤壁、基于時(shí)間

• TTL（Time To Live吩屹，即存活期）緩存數(shù)據(jù)從創(chuàng)建到過(guò)期的時(shí)間。
• TTI（Time To Idle拧抖，即空閑期）緩存數(shù)據(jù)多久沒(méi)被訪問(wèn)的時(shí)間煤搜。

1.4.2 緩存淘汰算法

• 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)頻率很高給擠出徒仓。

• 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ù)被淘汰壁晒。

• 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。

二晤斩、緩存的分類(lèi)

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

2.1 客戶端緩存

• HTTP 緩存
• 瀏覽器緩存
• APP 緩存（Android澳泵、iOS）

2.2 服務(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ù)緩存一般由專(zhuān)職人員維護(hù)（運(yùn)維、DBA）勉失。后端開(kāi)發(fā)一般聚焦于進(jìn)程內(nèi)緩存羹蚣、分布式緩存。

2.3 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)速度和命中率砌烁。

1

2.3.1 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)求荣月。

2.3.1.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)過(guò) 3 個(gè)節(jié)點(diǎn)，6 個(gè)步驟完成一次用戶訪問(wèn)操作哺窄。

2.3.1.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)過(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)速度啤握。

2.3.2 CDN 特點(diǎn)

2.3.2.1 優(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ì)量。

2.3.2.2 缺點(diǎn)

• 不適宜緩存動(dòng)態(tài)資源乞娄。
  解決方案：主要緩存靜態(tài)資源瞬逊，動(dòng)態(tài)資源建立多級(jí)緩存或準(zhǔn)實(shí)時(shí)同步显歧。
• 存在數(shù)據(jù)的一致性問(wèn)題。
  1.解決方案（主要是在性能和數(shù)據(jù)一致性二者間尋找一個(gè)平衡）确镊。
  2.設(shè)置緩存失效時(shí)間（1 個(gè)小時(shí)士骤，過(guò)期后同步數(shù)據(jù)）。
  3.針對(duì)資源設(shè)置版本號(hào)骚腥。

2.4 反向代理緩存

反向代理（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ù)器。

2

2.4.1 反向代理緩存原理

反向代理位于應(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裳涛。

2.4.2 反向代理緩存比較

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

• Varnish 和 Squid 是專(zhuān)業(yè)的 cache 服務(wù)，Ngnix 需要第三方模塊支持鹃彻；
• Varnish 采用內(nèi)存型緩存郊闯，避免了頻繁在內(nèi)存、磁盤(pán)中交換文件蛛株，性能比 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ù)緩存到硬盤(pán)或內(nèi)存组贺。

• 硬盤(pán)緩存：將數(shù)據(jù)緩存到硬盤(pán)中凸舵，讀取時(shí)從硬盤(pán)讀取。原理是直接讀取本機(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人断。

3.1 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)涩金。

3.2 LRUHashMap

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

缺點(diǎn)：

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

3.3 Guava Cache

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

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

3.4 Caffeine

Caffeine 實(shí)現(xiàn)了 W-TinyLFU(LFU + LRU 算法的變種)簿透，其命中率和讀寫(xiě)吞吐量大大優(yōu)于 Guava Cache移袍。其實(shí)現(xiàn)原理較復(fù)雜

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)存和磁盤(pán)，因此無(wú)需擔(dān)心容量問(wèn)題奄妨；
• 緩存數(shù)據(jù)會(huì)在虛擬機(jī)重啟的過(guò)程中寫(xiě)入磁盤(pán)涂籽；
• 可以通過(guò) RMI、可插入 API 等方式進(jìn)行分布式緩存砸抛；
• 具有緩存和緩存管理器的偵聽(tīng)接口评雌；
• 支持多緩存管理器實(shí)例，以及一個(gè)實(shí)例的多個(gè)緩存區(qū)域直焙；
• 提供 Hibernate 的緩存實(shí)現(xiàn)景东。

缺點(diǎn)：

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

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

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

3

• ConcurrentHashMap：比較適合緩存比較固定不變的元素和措，且緩存的數(shù)量較小的。雖然從上面表格中比起來(lái)有點(diǎn)遜色蜕煌，但是其由于是 JDK 自帶的類(lèi)派阱，在各種框架中依然有大量的使用，比如我們可以用來(lái)緩存我們反射的 Method斜纪，F(xiàn)ield 等等贫母；也可以緩存一些鏈接故响，防止其重復(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：其在命中率，讀寫(xiě)性能上都比 Guava Cache 好很多秸滴，并且其 API 和 Guava cache 基本一致武契，甚至?xí)嘁稽c(diǎn)。在真實(shí)環(huán)境中使用 Caffeine荡含，取得過(guò)不錯(cuò)的效果咒唆。

四、分布式緩存

分布式緩存解決了進(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ō)明找前。

4.1 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)存中讀取，從而大大提高讀取速度仿耽。

4.1.1 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ì)丟失知残。

4.1.2 Memcached 工作原理

4.1.2.1 內(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)溉委。

4.1.2.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ì)是否過(guò)期棵帽，而是在獲取 key 值時(shí)查看記錄的時(shí)間戳熄求，檢查 key/value 對(duì)空間是否過(guò)期，這樣可減輕服務(wù)器的負(fù)載岖寞。

4.1.2.3 分區(qū)

Memcached 服務(wù)器之間彼此不通信抡四，它的分布式能力是依賴(lài)客戶端來(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)讀/寫(xiě)淑履。而這種選取集群節(jié)點(diǎn)的算法常見(jiàn)的有三種：哈希取余算法、一致性哈希算法藻雪、虛擬 Hash 槽算法

4.2 Redis

Redis 是一個(gè)開(kāi)源（BSD 許可）的秘噪，基于內(nèi)存的，多數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)系統(tǒng)勉耀≈讣澹可以用作數(shù)據(jù)庫(kù)、緩存和消息中間件便斥。Redis 還可以使用客戶端分片來(lái)擴(kuò)展寫(xiě)性能至壤。內(nèi)置了 復(fù)制（replication），LUA 腳本（Lua scripting）枢纠，LRU 驅(qū)動(dòng)事件（LRU eviction）像街，事務(wù)（transactions） 和不同級(jí)別的 磁盤(pán)持久化（persistence）， 并通過(guò) Redis 哨兵（Sentinel）和自動(dòng)分區(qū)（Cluster）提供高可用性（high availability）晋渺。

4.2.1 Redis 特性

• 支持多種數(shù)據(jù)類(lèi)型：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 提供集群模式论寨。

4.2.2 Redis 原理

4.2.2.1 緩存淘汰

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

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

4.2.2.2 分區(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)谦疾。

4.2.2.3 主從復(fù)制

• Redis 2.8 后支持異步復(fù)制南蹂。它有兩種模式：
  1、完整重同步（full resychronization） - 用于初次復(fù)制念恍。執(zhí)行步驟與 SYNC 命令基本一致六剥。
  2、部分重同步（partial resychronization） - 用于斷線后重復(fù)制峰伙。如果條件允許疗疟，主服務(wù)器可以將主從服務(wù)器連接斷開(kāi)期間執(zhí)行的寫(xiě)命令發(fā)送給從服務(wù)器，從服務(wù)器只需接收并執(zhí)行這些寫(xiě)命令瞳氓，即可將主從服務(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)。

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

• Redis 不保證強(qiáng)一致性囊咏，因?yàn)檫@會(huì)使得集群性能大大降低恕洲。
• Redis 是通過(guò)異步復(fù)制來(lái)實(shí)現(xiàn)最終一致性。

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

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

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

五搬卒、多級(jí)緩存

5.1 整體緩存框架

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

4

請(qǐng)求過(guò)程：
1、瀏覽器向客戶端發(fā)起請(qǐng)求秀睛，如果 CDN 有緩存則直接返回尔当；
2、如果 CDN 無(wú)緩存蹂安，則訪問(wèn)反向代理服務(wù)器椭迎；
3、如果反向代理服務(wù)器有緩存則直接返回田盈；
4畜号、如果反向代理服務(wù)器無(wú)緩存或動(dòng)態(tài)請(qǐng)求，則訪問(wèn)應(yīng)用服務(wù)器允瞧；
5简软、應(yīng)用服務(wù)器訪問(wèn)進(jìn)程內(nèi)緩存；如果有緩存述暂，則返回代理服務(wù)器痹升，并緩存數(shù)據(jù)（動(dòng)態(tài)請(qǐng)求不緩存）；
6畦韭、如果進(jìn)程內(nèi)緩存無(wú)數(shù)據(jù)疼蛾，則讀取分布式緩存；并返回應(yīng)用服務(wù)器艺配；應(yīng)用服務(wù)器將數(shù)據(jù)緩存到本地緩存（部分）察郁；
7、如果分布式緩存無(wú)數(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)緩存，其本來(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ò)展。

5.3 使用分布式緩存

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

5

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)銷(xiāo)般渡，雖然性能很高懒豹，但是其終究沒(méi)有在內(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)一步提升訪問(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í)緩存稳衬。

5.4.1 多級(jí)緩存查詢

6

多級(jí)緩存查詢流程如下：
1、首先坐漏，查詢 L1 緩存薄疚，如果緩存命中碧信，直接返回結(jié)果；如果沒(méi)有命中街夭，執(zhí)行下一步砰碴。
2、接下來(lái)板丽，查詢 L2 緩存呈枉，如果緩存命中，直接返回結(jié)果并回填 L1 緩存埃碱；如果沒(méi)有命中猖辫，執(zhí)行下一步。
3乃正、最后住册，查詢數(shù)據(jù)庫(kù)，返回結(jié)果并依次回填 L2 緩存瓮具、L1 緩存荧飞。

5.4.2 多級(jí)緩存更新

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

• 設(shè)置成寫(xiě)入后多少時(shí)間后過(guò)期传睹；
• 設(shè)置成寫(xiě)入后多少時(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)化倒慧；

7

通過(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)題

6.1 緩存雪崩

緩存雪崩是指緩存不可用或者大量緩存由于超時(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ā)生了全盤(pán)宕機(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 的高可用骡技，避免全盤(pán)崩潰。
• 采用多級(jí)緩存方案（事中）羞反。例如：本地緩存（Ehcache/Caffine/Guava Cache） + 分布式緩存（Redis/ Memcached）布朦。
• 限流、降級(jí)昼窗、熔斷方案（事中）是趴，避免被流量打死。如：使用 Hystrix 進(jìn)行熔斷膏秫、降級(jí)右遭。
• 緩存如果支持持久化，可以在恢復(fù)工作后恢復(fù)數(shù)據(jù)（事后）缤削。如：Redis 支持持久化窘哈，一旦重啟，自動(dòng)從磁盤(pán)上加載數(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í)間不同淹辞。

6.2 緩存穿透

緩存穿透是指：查詢的數(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)行緩存录肯。

6.3 緩存擊穿

緩存擊穿是指，熱點(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)刷新也可以。

6.4 小結(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)從磁盤(pán)上加載數(shù)據(jù)谜酒，快速恢復(fù)緩存數(shù)據(jù)叹俏。

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

七愕掏、緩存策略

7.1 緩存預(yù)熱

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

解決方案：

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

7.2 如何緩存

7.2.1 不過(guò)期緩存

• 緩存更新模式：
• 開(kāi)啟事務(wù)酪刀；
• 寫(xiě) SQL粹舵；
• 提交事務(wù)；
• 寫(xiě)緩存骂倘；

不要把寫(xiě)緩存操作放在事務(wù)中眼滤，尤其是寫(xiě)分布式緩存。因?yàn)榫W(wǎng)絡(luò)抖動(dòng)可能導(dǎo)致寫(xiě)緩存響應(yīng)時(shí)間很慢历涝，引起數(shù)據(jù)庫(kù)事務(wù)阻塞诅需。如果對(duì)緩存數(shù)據(jù)一致性要求不是那么高，數(shù)據(jù)量也不是很大睬关，可以考慮定期全量同步緩存诱担。這種模式存在這樣的情況：存在事務(wù)成功，但緩存寫(xiě)失敗的可能电爹。但這種情況相對(duì)于上面的問(wèn)題蔫仙，影響較小。

7.2.2 過(guò)期緩存

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

7.3 緩存更新

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

八、總結(jié)

8

轉(zhuǎn)載自：解析分布式系統(tǒng)的緩存設(shè)計(jì)