推薦??：接近100K star 的Java學(xué)習(xí)/面試指南：JavaGuide

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

在我看來(lái)挺勿，造成這個(gè)問(wèn)題的原因是我們?cè)趯W(xué)習(xí) Redis 的時(shí)候曲横，可能只是簡(jiǎn)單了寫一些 Demo，并沒(méi)有去關(guān)注緩存的讀寫策略不瓶，或者說(shuō)壓根不知道這回事禾嫉。

但是，搞懂3種常見(jiàn)的緩存讀寫策略對(duì)于實(shí)際工作中使用緩存以及面試中被問(wèn)到緩存都是非常有幫助的蚊丐！

下面我會(huì)簡(jiǎn)單介紹一下自己對(duì)于這 3 種緩存讀寫策略的理解熙参。

另外，這3 種緩存讀寫策略各有優(yōu)劣麦备，不存在最佳孽椰，需要我們根據(jù)具體的業(yè)務(wù)場(chǎng)景選擇更適合的。

個(gè)人能力有限凛篙。如果文章有任何需要補(bǔ)充/完善/修改的地方黍匾，歡迎在評(píng)論區(qū)指出，共同進(jìn)步呛梆！——愛(ài)你們的 Guide 哥

Cache Aside Pattern（旁路緩存模式）

Cache Aside Pattern 是我們平時(shí)使用比較多的一個(gè)緩存讀寫模式膀捷，比較適合讀請(qǐng)求比較多的場(chǎng)景。

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

下面我們來(lái)看一下這個(gè)策略模式下的緩存讀寫步驟秀仲。

寫 ：

• 先更新 DB
• 然后直接刪除 cache 融痛。

簡(jiǎn)單畫(huà)了一張圖幫助大家理解寫的步驟。

讀 :

• 從 cache 中讀取數(shù)據(jù)神僵，讀取到就直接返回
• cache中讀取不到的話雁刷，就從 DB 中讀取數(shù)據(jù)返回
• 再把數(shù)據(jù)放到 cache 中。

簡(jiǎn)單畫(huà)了一張圖幫助大家理解讀的步驟保礼。

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

比如說(shuō)面試官很可能會(huì)追問(wèn)：“在寫數(shù)據(jù)的過(guò)程中炮障，可以先刪除 cache 目派，后更新 DB 么？”

答案： 那肯定是不行的胁赢！因?yàn)檫@樣可能會(huì)造成數(shù)據(jù)庫(kù)（DB）和緩存（Cache）數(shù)據(jù)不一致的問(wèn)題企蹭。為什么呢？比如說(shuō)請(qǐng)求1 先寫數(shù)據(jù)A，請(qǐng)求2隨后讀數(shù)據(jù)A的話就很有可能產(chǎn)生數(shù)據(jù)不一致性的問(wèn)題谅摄。這個(gè)過(guò)程可以簡(jiǎn)單描述為：

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

當(dāng)你這樣回答之后，面試官可能會(huì)緊接著就追問(wèn)：“在寫數(shù)據(jù)的過(guò)程中送漠，先更新DB顽照，后刪除cache就沒(méi)有問(wèn)題了么？”

答案： 理論上來(lái)說(shuō)還是可能會(huì)出現(xiàn)數(shù)據(jù)不一致性的問(wèn)題闽寡，不過(guò)概率非常小代兵，因?yàn)榫彺娴膶懭胨俣仁潜葦?shù)據(jù)庫(kù)的寫入速度快很多！

比如請(qǐng)求1先讀數(shù)據(jù) A下隧，請(qǐng)求2隨后寫數(shù)據(jù)A奢人，并且數(shù)據(jù)A不在緩存中的話也有可能產(chǎn)生數(shù)據(jù)不一致性的問(wèn)題。這個(gè)過(guò)程可以簡(jiǎn)單描述為：

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

現(xiàn)在我們?cè)賮?lái)分析一下 Cache Aside Pattern 的缺陷何乎。

缺陷1：首次請(qǐng)求數(shù)據(jù)一定不在 cache 的問(wèn)題

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

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

解決辦法：

• 數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)強(qiáng)一致場(chǎng)景 ：更新DB的時(shí)候同樣更新cache，不過(guò)我們需要加一個(gè)鎖/分布式鎖來(lái)保證更新cache的時(shí)候不存在線程安全問(wèn)題拷淘。
• 可以短暫地允許數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)不一致的場(chǎng)景 ：更新DB的時(shí)候同樣更新cache各墨，但是給緩存加一個(gè)比較短的過(guò)期時(shí)間，這樣的話就可以保證即使數(shù)據(jù)不一致的話影響也比較小启涯。

Read/Write Through Pattern（讀寫穿透）

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

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

寫（Write Through）：

• 先查 cache，cache 中不存在鸣峭，直接更新 DB宏所。
• cache 中存在，則先更新 cache摊溶，然后 cache 服務(wù)自己更新 DB（同步更新 cache 和 DB）爬骤。

簡(jiǎn)單畫(huà)了一張圖幫助大家理解寫的步驟。

讀(Read Through)：

• 從 cache 中讀取數(shù)據(jù)莫换，讀取到就直接返回 盖腕。
• 讀取不到的話赫冬，先從 DB 加載，寫入到 cache 后返回響應(yīng)溃列。

簡(jiǎn)單畫(huà)了一張圖幫助大家理解讀的步驟劲厌。

Read-Through Pattern 實(shí)際只是在 Cache-Aside Pattern 之上進(jìn)行了封裝。在 Cache-Aside Pattern 下听隐，發(fā)生讀請(qǐng)求的時(shí)候补鼻，如果 cache 中不存在對(duì)應(yīng)的數(shù)據(jù)，是由客戶端自己負(fù)責(zé)把數(shù)據(jù)寫入 cache雅任，而 Read Through Pattern 則是 cache 服務(wù)自己來(lái)寫入緩存的风范，這對(duì)客戶端是透明的。

和 Cache Aside Pattern 一樣沪么， Read-Through Pattern 也有首次請(qǐng)求數(shù)據(jù)一定不再 cache 的問(wèn)題硼婿，對(duì)于熱點(diǎn)數(shù)據(jù)可以提前放入緩存中。

Write Behind Pattern（異步緩存寫入）

Write Behind Pattern 和 Read/Write Through Pattern 很相似禽车，兩者都是由 cache 服務(wù)來(lái)負(fù)責(zé) cache 和 DB 的讀寫寇漫。

但是，兩個(gè)又有很大的不同：Read/Write Through 是同步更新 cache 和 DB殉摔，而 Write Behind Caching 則是只更新緩存州胳，不直接更新 DB，而是改為異步批量的方式來(lái)更新 DB逸月。

很明顯栓撞，這種方式對(duì)數(shù)據(jù)一致性帶來(lái)了更大的挑戰(zhàn)，比如cache數(shù)據(jù)可能還沒(méi)異步更新DB的話碗硬，cache服務(wù)可能就就掛掉了瓤湘。

這種策略在我們平時(shí)開(kāi)發(fā)過(guò)程中也非常非常少見(jiàn)，但是不代表它的應(yīng)用場(chǎng)景少恩尾，比如消息隊(duì)列中消息的異步寫入磁盤岭粤、MySQL 的 InnoDB Buffer Pool 機(jī)制都用到了這種策略。

Write Behind Pattern 下 DB 的寫性能非常高特笋，非常適合一些數(shù)據(jù)經(jīng)常變化又對(duì)數(shù)據(jù)一致性要求沒(méi)那么高的場(chǎng)景，比如瀏覽量巾兆、點(diǎn)贊量猎物。

我的Github地址：Snailclimb - Overview