推薦?：接近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
