一肩豁、緩存簡(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ù)緩存到離用戶(hù)最近的位置。

緩存是用于存儲(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ù)連接池比較繁忙，可以考慮緩存其查詢(xún)結(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ā))：先查詢(xún) 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 緩存淘汰策略

緩存淘汰的類(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）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赊时。

二吨铸、緩存的分類(lèi)

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

客戶(hù)端緩存

• HTTP 緩存

• 瀏覽器緩存

• APP 緩存（1诞吱、Android 2、IOS）

服務(wù)端緩存

• CDN 緩存：存放 HTML竭缝、CSS房维、JS 等靜態(tài)資源。

• 反向代理緩存：動(dòng)靜分離抬纸，只緩存用戶(hù)請(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.1 HTTP 緩存

2.2 CDN 緩存

CDN 將數(shù)據(jù)緩存到離用戶(hù)物理距離最近的服務(wù)器卵史，使得用戶(hù)可以就近獲取請(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)商或各地用戶(hù)訪問(wèn)問(wèn)題址晕，可以在重要的城市，部署 CDN 應(yīng)用顿锰。使用戶(hù)就近獲取所需內(nèi)容谨垃，降低網(wǎng)絡(luò)擁塞，提高用戶(hù)訪問(wèn)響應(yīng)速度和命中率硼控。

[圖片上傳失敗...(image-a4d415-1649751378076)]

圖片引用自：Why use a CDN

2.1.1 CDN 原理

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

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è)步驟完成一次用戶(hù)訪問(wèn)操作。

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è)步驟完成一次用戶(hù)訪問(wèn)操作。與不部署 CDN 服務(wù)相比曲横，減少了 1 個(gè)節(jié)點(diǎn)饵史，4 個(gè)步驟的訪問(wèn)。極大的提高了系統(tǒng)的響應(yīng)速度胜榔。

2.1.2 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ò)中的用戶(hù)都能得到良好的訪問(wèn)質(zhì)量吠撮；

• 遠(yuǎn)程加速：遠(yuǎn)程訪問(wèn)用戶(hù)根據(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)程用戶(hù)訪問(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)題

1.解決方案（主要是在性能和數(shù)據(jù)一致性二者間尋找一個(gè)平衡）神僵。

2.設(shè)置緩存失效時(shí)間（1 個(gè)小時(shí)，過(guò)期后同步數(shù)據(jù)）覆劈。

3.針對(duì)資源設(shè)置版本號(hào)保礼。

2.2 反向代理緩存

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

[圖片上傳失敗...(image-ebfd8b-1649751378077)]

2.2.1 反向代理緩存原理

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

• 如果用戶(hù)請(qǐng)求的頁(yè)面在代理服務(wù)器上有緩存的話，代理服務(wù)器直接將緩存內(nèi)容發(fā)送給用戶(hù)铐拐。

• 如果沒(méi)有緩存則先向 WEB 服務(wù)器發(fā)出請(qǐng)求徘键，取回?cái)?shù)據(jù)，本地緩存后再發(fā)送給用戶(hù)遍蟋。

這種方式通過(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.2.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ò)查詢(xún)，判斷其是否滿(mǎn)足刷新條件氯迂，進(jìn)行刷新茬贵。

3.4 Caffeine

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

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ì)比：

[圖片上傳失敗...(image-90cd15-1649751378077)]

• 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ò)的效果。

總結(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ō)明杆怕。

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)查詢(xún)時(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 客戶(hù)端爱只，服務(wù)器之間互不通信。各個(gè) Memcached 服務(wù)器之間互不通信招刹，各自獨(dú)立存取數(shù)據(jù)恬试，不共享任何信息窝趣。服務(wù)器并不具有分布式功能，分布式部署取決于 Memcached 客戶(hù)端训柴。

• 采用 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)存滿(mǎn)后蝠咆，通過(guò) LRU 算法自動(dòng)刪除不使用的緩存踊东。

• 不支持持久化。Memcached 沒(méi)有考慮數(shù)據(jù)的容災(zāi)問(wèn)題刚操，重啟服務(wù)闸翅，所有數(shù)據(jù)會(huì)丟失。

4.1.2 Memcached 工作原理

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)滑凉。

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ù)載隙疚。

3）分區(qū)

Memcached 服務(wù)器之間彼此不通信帚湘，它的分布式能力是依賴(lài)客戶(hù)端來(lái)實(shí)現(xiàn)。具體來(lái)說(shuō)甚淡，就是在客戶(hù)端實(shí)現(xiàn)一種算法，根據(jù) key 來(lái)計(jì)算出數(shù)據(jù)應(yīng)該向哪個(gè)服務(wù)器節(jié)點(diǎn)讀/寫(xiě)捅厂。

而這種選取集群節(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ù)量的槽吃衅。

4.2 Redis

Redis 是一個(gè)開(kāi)源（BSD 許可）的往踢，基于內(nèi)存的，多數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)系統(tǒng)徘层【唬可以用作數(shù)據(jù)庫(kù)、緩存和消息中間件趣效。

Redis 還可以使用客戶(hù)端分片來(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 原理

1）緩存淘汰

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

• 消極方式：訪問(wèn) Redis key 時(shí)党巾，如果發(fā)現(xiàn)它已經(jīng)失效萎庭，則刪除它

• 積極方式：周期性從設(shè)置了失效時(shí)間的 key 中，根據(jù)淘汰策略齿拂，選擇一部分失效的 key 進(jìn)行刪除驳规。

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)將向客戶(hù)端返回一個(gè) MOVED 錯(cuò)誤捻勉，MOVED 錯(cuò)誤攜帶的信息可以指引客戶(hù)端將請(qǐng)求重定向至正在負(fù)責(zé)相關(guān)槽的節(jié)點(diǎn)。

3）主從復(fù)制

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

完整重同步（full resychronization） - 用于初次復(fù)制贯底。執(zhí)行步驟與 SYNC 命令基本一致。

部分重同步（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）數(shù)據(jù)一致性

• Redis 不保證強(qiáng)一致性，因?yàn)檫@會(huì)使得集群性能大大降低孽拷。

• Redis 是通過(guò)異步復(fù)制來(lái)實(shí)現(xiàn)最終一致性吨掌。

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

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

[圖片上傳失敗...(image-430d50-1649751378077)]

這里選取三個(gè)比較出名的分布式緩存（MemCache膜宋，Redis，Tair）來(lái)作為比較：

[圖片上傳失敗...(image-b94716-1649751378077)]

• 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í)緩存方案：

[圖片上傳失敗...(image-2f4c3b-1649751378077)]

請(qǐng)求過(guò)程：

• 瀏覽器向客戶(hù)端發(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ù)，并放入分布式緩存调限；

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)景如圖所示：

[圖片上傳失敗...(image-4f7cc7-1649751378077)]

Redis 用來(lái)存儲(chǔ)熱點(diǎn)數(shù)據(jù)普办，如果緩存不命中工扎，則去查詢(xún)數(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)存中查詢(xún)快沙廉。

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í)緩存已可以滿(mǎn)足大部分業(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í)緩存查詢(xún)

[圖片上傳失敗...(image-9a2031-1649751378077)]

多級(jí)緩存查詢(xún)流程如下：

• 首先，查詢(xún) L1 緩存颤专，如果緩存命中纽哥，直接返回結(jié)果；如果沒(méi)有命中栖秕，執(zhí)行下一步春塌。

• 接下來(lái)，查詢(xún) L2 緩存簇捍，如果緩存命中摔笤，直接返回結(jié)果并回填 L1 緩存；如果沒(méi)有命中垦写，執(zhí)行下一步。

• 最后彰触，查詢(xún)數(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)化蕊退；

[圖片上傳失敗...(image-7e7bf5-1649751378077)]

通過(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è)查詢(xún)請(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 緩存穿透

緩存穿透是指：查詢(xún)的數(shù)據(jù)在數(shù)據(jù)庫(kù)中不存在霉撵，那么緩存中自然也不存在磺浙。所以，應(yīng)用在緩存中查不到喊巍，則會(huì)去查詢(xún)數(shù)據(jù)庫(kù)。當(dāng)這樣的請(qǐng)求多了后箍鼓，數(shù)據(jù)庫(kù)的壓力就會(huì)增大崭参。

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

1）緩存空值

對(duì)于返回為 NULL 的依然緩存款咖，對(duì)于拋出異常的返回不進(jìn)行緩存何暮。

[圖片上傳失敗...(image-c3e778-1649751378077)]

采用這種手段的會(huì)增加我們緩存的維護(hù)成本奄喂，需要在插入緩存的時(shí)候刪除這個(gè)空緩存，當(dāng)然我們可以通過(guò)設(shè)置較短的超時(shí)時(shí)間來(lái)解決這個(gè)問(wèn)題海洼。

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

[圖片上傳失敗...(image-9dde22-1649751378077)]

制定一些規(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)后徽鼎，直接查詢(xún)熱點(diǎn)數(shù)據(jù)并緩存盛末。這樣就可以避免用戶(hù)請(qǐng)求的時(shí)候，先查詢(xún)數(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)的吞吐量大幅度下降惰匙。

一般來(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ō)考慮刪除緩存吠卷。

• 先刪除緩存，再更新數(shù)據(jù)庫(kù)稚虎；

對(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ù)祭钉。

[圖片上傳失敗...(image-da3cc3-1649751378077)]

對(duì)緩存的操作不論成功失敗都不能阻塞我們對(duì)數(shù)據(jù)庫(kù)的操作瞄沙，那么很多時(shí)候刪除緩存可以用異步的操作，但是先刪除緩存不能很好的適用于這個(gè)場(chǎng)景。先刪除緩存也有一個(gè)好處是距境，如果對(duì)數(shù)據(jù)庫(kù)操作失敗了申尼，那么由于先刪除的緩存，最多只是造成 Cache Miss垫桂。

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

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

但是同樣的引入了新的問(wèn)題：假設(shè)執(zhí)行更新操作時(shí)，又接收到查詢(xún)請(qǐng)求疼鸟，此時(shí)就會(huì)返回緩存中的老數(shù)據(jù)后控。更麻煩的是，如果數(shù)據(jù)庫(kù)更新操作執(zhí)行失敗空镜，則緩存中可能永遠(yuǎn)是臟數(shù)據(jù)浩淘。

2）應(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ā)寫(xiě)操作茴厉。而實(shí)際上數(shù)據(jù)庫(kù)的寫(xiě)操作會(huì)比讀操作慢得多泽台，而且還要鎖表，而讀操作必需在寫(xiě)操作前進(jìn)入數(shù)據(jù)庫(kù)操作矾缓，而又要晚于寫(xiě)操作更新緩存怀酷，所有的這些條件都具備的概率基本并不大。

如果需要數(shù)據(jù)庫(kù)和緩存保證強(qiáng)一致性嗜闻，則可以通過(guò) 2PC 或 Paxos 協(xié)議來(lái)實(shí)現(xiàn)蜕依。但是 2PC 太慢，而 Paxos 太復(fù)雜琉雳，所以如果不是非常重要的數(shù)據(jù)样眠，不建議使用強(qiáng)一致性方案。更詳細(xì)的分析可以參考：分布式之?dāng)?shù)據(jù)庫(kù)和緩存雙寫(xiě)一致性方案解析翠肘。

八檐束、總結(jié)

最后，通過(guò)一張思維導(dǎo)圖來(lái)總結(jié)一下本文所述的知識(shí)點(diǎn)束倍，幫助大家對(duì)緩存有一個(gè)系統(tǒng)性的認(rèn)識(shí)被丧。

[圖片上傳失敗...(image-11417e-1649751378077)]

九盟戏、參考資料

1、《大型網(wǎng)站技術(shù)架構(gòu)：核心原理與案例分析》

2甥桂、你應(yīng)該知道的緩存進(jìn)化史

3柿究、如何優(yōu)雅的設(shè)計(jì)和使用緩存？

4黄选、理解分布式系統(tǒng)中的緩存架構(gòu)(上)

5笛求、緩存那些事

6、分布式之?dāng)?shù)據(jù)庫(kù)和緩存雙寫(xiě)一致性方案解析

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