看到很多小伙伴簡歷上寫了“熟練使用緩存”，但是被我問到“緩存常用的 3 種讀寫策略”的時(shí)候卻一臉懵逼缨硝。

造成這個(gè)問題的原因是我們在學(xué)習(xí) Redis 的時(shí)候，可能只是簡單了寫一些 Demo评凝，并沒有去關(guān)注緩存的讀寫策略追葡，或者說壓根不知道這回事。

但是奕短，搞懂3種常見的緩存讀寫策略對于實(shí)際工作中使用緩存以及面試中被問到緩存都是非常有幫助的宜肉！

下面我會簡單介紹一下自己對于這 3 種緩存讀寫策略的理解。

另外翎碑，這 3 種緩存讀寫策略各有優(yōu)劣谬返，不存在最佳，需要我們根據(jù)具體的業(yè)務(wù)場景選擇更適合的日杈。

Cache Aside Pattern（旁路緩存模式）

Cache Aside Pattern 是我們平時(shí)使用比較多的一個(gè)緩存讀寫模式遣铝，比較適合讀請求比較多的場景佑刷。

Cache Aside Pattern 中服務(wù)端需要同時(shí)維系 DB 和 cache，并且是以 DB 的結(jié)果為準(zhǔn)酿炸。

下面我們來看一下這個(gè)策略模式下的緩存讀寫步驟瘫絮。

寫?：

先更新 DB

然后直接刪除 cache 。

簡單畫了一張圖幫助大家理解寫的步驟填硕。

讀?:

從 cache 中讀取數(shù)據(jù)麦萤，讀取到就直接返回

cache 中讀取不到的話，就從 DB 中讀取數(shù)據(jù)返回

再把數(shù)據(jù)放到 cache 中扁眯。

簡單畫了一張圖幫助大家理解讀的步驟壮莹。

你僅僅了解了上面這些內(nèi)容的話是遠(yuǎn)遠(yuǎn)不夠的，我們還要搞懂其中的原理姻檀。

比如說面試官很可能會追問：“在寫數(shù)據(jù)的過程中命满，可以先刪除 cache ，后更新 DB 么绣版？”

答案：?那肯定是不行的胶台！因?yàn)檫@樣可能會造成數(shù)據(jù)庫（DB）和緩存（Cache）數(shù)據(jù)不一致的問題。為什么呢僵娃？比如說請求 1 先寫數(shù)據(jù) A概作，請求 2 隨后讀數(shù)據(jù) A 的話就很有可能產(chǎn)生數(shù)據(jù)不一致性的問題。這個(gè)過程可以簡單描述為：

請求 1 先把 cache 中的 A 數(shù)據(jù)刪除 -> 請求 2 從 DB 中讀取數(shù)據(jù)->請求 1 再把 DB 中的 A 數(shù)據(jù)更新默怨。

當(dāng)你這樣回答之后讯榕，面試官可能會緊接著就追問：“在寫數(shù)據(jù)的過程中，先更新 DB匙睹，后刪除 cache 就沒有問題了么愚屁？”

答案：理論上來說還是可能會出現(xiàn)數(shù)據(jù)不一致性的問題，不過概率非常小痕檬，因?yàn)榫彺娴膶懭胨俣仁潜葦?shù)據(jù)庫的寫入速度快很多霎槐！

比如請求 1 先讀數(shù)據(jù) A，請求 2 隨后寫數(shù)據(jù) A梦谜，并且數(shù)據(jù) A 不在緩存中的話也有可能產(chǎn)生數(shù)據(jù)不一致性的問題丘跌。這個(gè)過程可以簡單描述為：

請求 1 從 DB 讀數(shù)據(jù) A->請求 2 寫更新數(shù)據(jù) A 到數(shù)據(jù)庫并把刪除 cache 中的 A 數(shù)據(jù)->請求 1 將數(shù)據(jù) A 寫入 cache。

現(xiàn)在我們再來分析一下 Cache Aside Pattern 的缺陷唁桩。

缺陷 1：首次請求數(shù)據(jù)一定不存在 cache 的問題

解決辦法：可以將熱點(diǎn)數(shù)據(jù)可以提前放入 cache 中闭树。

缺陷 2：寫操作比較頻繁的話導(dǎo)致 cache 中的數(shù)據(jù)會被頻繁被刪除，這樣會影響緩存命中率 荒澡。

解決辦法：

數(shù)據(jù)庫和緩存數(shù)據(jù)強(qiáng)一致場景 ：更新 DB 的時(shí)候同樣更新 cache报辱，不過我們需要加一個(gè)鎖/分布式鎖來保證更新 cache 的時(shí)候不存在線程安全問題。

可以短暫地允許數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的場景 ：更新 DB 的時(shí)候同樣更新 cache单山，但是給緩存加一個(gè)比較短的過期時(shí)間碍现，這樣的話就可以保證即使數(shù)據(jù)不一致的話影響也比較小幅疼。

Read/Write Through Pattern（讀寫穿透）

Read/Write Through Pattern 中服務(wù)端把 cache 視為主要數(shù)據(jù)存儲，從中讀取數(shù)據(jù)并將數(shù)據(jù)寫入其中昼接。cache 服務(wù)負(fù)責(zé)將此數(shù)據(jù)讀取和寫入 DB爽篷，從而減輕了應(yīng)用程序的職責(zé)。

這種緩存讀寫策略小伙伴們應(yīng)該也發(fā)現(xiàn)了在平時(shí)在開發(fā)過程中非常少見慢睡。拋去性能方面的影響狼忱，大概率是因?yàn)槲覀兘?jīng)常使用的分布式緩存 Redis 并沒有提供 cache 將數(shù)據(jù)寫入 DB 的功能。

寫（Write Through）：

先查 cache一睁，cache 中不存在，直接更新 DB佃却。

cache 中存在者吁，則先更新 cache，然后 cache 服務(wù)自己更新 DB（同步更新 cache 和 DB）饲帅。

簡單畫了一張圖幫助大家理解寫的步驟复凳。

讀(Read Through)：

從 cache 中讀取數(shù)據(jù)，讀取到就直接返回 灶泵。

讀取不到的話育八，先從 DB 加載，寫入到 cache 后返回響應(yīng)赦邻。

簡單畫了一張圖幫助大家理解讀的步驟髓棋。

Read-Through Pattern 實(shí)際只是在 Cache-Aside Pattern 之上進(jìn)行了封裝。在 Cache-Aside Pattern 下惶洲，發(fā)生讀請求的時(shí)候按声，如果 cache 中不存在對應(yīng)的數(shù)據(jù)，是由客戶端自己負(fù)責(zé)把數(shù)據(jù)寫入 cache恬吕，而 Read Through Pattern 則是 cache 服務(wù)自己來寫入緩存的签则，這對客戶端是透明的。

和 Cache Aside Pattern 一樣铐料， Read-Through Pattern 也有首次請求數(shù)據(jù)一定不在 cache 的問題渐裂，對于熱點(diǎn)數(shù)據(jù)可以提前放入緩存中。

Write Behind Pattern（異步緩存寫入）

Write Behind Pattern 和 Read/Write Through Pattern 很相似钠惩，兩者都是由 cache 服務(wù)來負(fù)責(zé) cache 和 DB 的讀寫柒凉。

但是，兩個(gè)又有很大的不同：Read/Write Through 是同步更新 cache 和 DB妻柒，而 Write Behind Caching 則是只更新緩存扛拨，不直接更新 DB，而是改為異步批量的方式來更新 DB举塔。

很明顯绑警，這種方式對數(shù)據(jù)一致性帶來了更大的挑戰(zhàn)求泰，比如 cache 數(shù)據(jù)可能還沒異步更新 DB 的話，cache 服務(wù)可能就掛掉了计盒。

這種策略在我們平時(shí)開發(fā)過程中也非常少見渴频，但是不代表它的應(yīng)用場景少，比如消息隊(duì)列中消息的異步寫入磁盤北启、MySQL 的 InnoDB Buffer Pool 機(jī)制都用到了這種策略卜朗。

Write Behind Pattern 下 DB 的寫性能非常高，非常適合一些數(shù)據(jù)經(jīng)常變化又對數(shù)據(jù)一致性要求沒那么高的場景咕村，比如瀏覽量场钉、點(diǎn)贊量。