[[356557]]

本文轉(zhuǎn)載自微信公眾號「JavaGuide」，作者Guide哥 。轉(zhuǎn)載本文請聯(lián)系JavaGuide公眾號。 

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

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

但是，搞懂 3 種常見的緩存讀寫策略對于實際工作中使用緩存以及面試中被問到緩存都是非常有幫助的!

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

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

個人能力有限。如果文章有任何需要補充/完善/修改的地方，歡迎在評論區(qū)指出，共同進步!——愛你們的 Guide哥

Cache Aside Pattern(旁路緩存模式)

Cache Aside Pattern 是我們平時使用比較多的一個緩存讀寫模式，比較適合讀請求比較多的場景。

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

下面我們來看一下這個策略模式下的緩存讀寫步驟。

寫 ：

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

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

讀 :

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

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

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

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

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

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

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

答案：理論上來說還是可能會出現(xiàn)數(shù)據(jù)不一致性的問題，不過概率非常小，因為緩存的寫入速度是比數(shù)據(jù)庫的寫入速度快很多!

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

請求 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 的問題

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

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

解決辦法：

• 數(shù)據(jù)庫和緩存數(shù)據(jù)強一致場景 ：更新 DB 的時候同樣更新 cache，不過我們需要加一個鎖/分布式鎖來保證更新 cache 的時候不存在線程安全問題。
• 可以短暫地允許數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的場景 ：更新 DB 的時候同樣更新 cache，但是給緩存加一個比較短的過期時間，這樣的話就可以保證即使數(shù)據(jù)不一致的話影響也比較小。

Read/Write Through Pattern(讀寫穿透)

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

這種緩存讀寫策略小伙伴們應(yīng)該也發(fā)現(xiàn)了在平時在開發(fā)過程中非常少見。拋去性能方面的影響，大概率是因為我們經(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 實際只是在 Cache-Aside Pattern 之上進行了封裝。在 Cache-Aside Pattern 下，發(fā)生讀請求的時候，如果 cache 中不存在對應(yīng)的數(shù)據(jù)，是由客戶端自己負責(zé)把數(shù)據(jù)寫入 cache，而 Read Through Pattern 則是 cache 服務(wù)自己來寫入緩存的，這對客戶端是透明的。

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

Write Behind Pattern(異步緩存寫入)

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

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

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

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

原文鏈接：https://mp.weixin.qq.com/s/bWofuM5eS2Q8ylF-4AD0kA