推薦??：接近100K star 的Java學習/面試指南：JavaGuide

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

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

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

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

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

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

Cache Aside Pattern（旁路緩存模式）

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

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

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

寫 ：

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

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

讀 :

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

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

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

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

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

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

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

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

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

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

現在我們再來分析一下 Cache Aside Pattern 的缺陷。

缺陷1：首次請求數據一定不在 cache 的問題

解決辦法：可以將熱點數據可以提前放入cache 中。

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

解決辦法：

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

Read/Write Through Pattern（讀寫穿透）

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

這種緩存讀寫策略小伙伴們應該也發現了在平時在開發過程中非常少見。拋去性能方面的影響，大概率是因為我們經常使用的分布式緩存 Redis 并沒有提供 cache 將數據寫入DB的功能。

寫（Write Through）：

• 先查 cache，cache 中不存在，直接更新 DB。
• cache 中存在，則先更新 cache，然后 cache 服務自己更新 DB（同步更新 cache 和 DB）。

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

讀(Read Through)：

• 從 cache 中讀取數據，讀取到就直接返回 。
• 讀取不到的話，先從 DB 加載，寫入到 cache 后返回響應。

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

Read-Through Pattern 實際只是在 Cache-Aside Pattern 之上進行了封裝。在 Cache-Aside Pattern 下，發生讀請求的時候，如果 cache 中不存在對應的數據，是由客戶端自己負責把數據寫入 cache，而 Read Through Pattern 則是 cache 服務自己來寫入緩存的，這對客戶端是透明的。

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

Write Behind Pattern（異步緩存寫入）

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

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

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

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

Write Behind Pattern 下 DB 的寫性能非常高，非常適合一些數據經常變化又對數據一致性要求沒那么高的場景，比如瀏覽量、點贊量。

我的Github地址：Snailclimb - Overview