概述

在系統架構中，快取可謂提供系統效能的最簡單方法之一，稍微有點開發經驗的同學必然會與快取打過交道，最起碼也實踐過。

如果使用得當，快取可以減少響應時間、減少資料庫負載以及節省成本。但如果快取使用不當，則可能出現一些莫名其妙的問題。

在不同的場景下，所使用的快取策略也是有變化的。如果在你的印象和經驗中，快取還只是簡單的查詢、更新操作，那麼這篇文章真的值得你學習一下。

在這裡，為大家系統地講解4種快取模式以及它們的使用場景、流程以及優缺點。

快取策略的選擇

本質上來講，快取策略取決於資料和資料訪問模式。換句話說，資料是如何寫和讀的。

例如:

• 系統是寫多讀少的嗎？（例如，基於時間的日誌）
• 資料是否是隻寫入一次並被讀取多次？（例如，使用者配置檔案）
• 返回的資料總是唯一的嗎？（例如，搜尋查詢）

選擇正確的快取策略才是提高效能的關鍵。

常用的快取策略有以下五種：

• Cache-Aside Pattern：旁路快取模式

• Read Through Cache Pattern：讀穿透模式

• Write Through Cache Pattern：寫穿透模式

• Write Behind Pattern：又叫Write Back，非同步快取寫入模式

上述快取策略的劃分是基於對資料的讀寫流程來區分的，有的快取策略下是應用程式僅和快取互動，有的快取策略下應用程式同時與快取和資料庫進行互動。因為這個是策略劃分比較重要的一個維度，所以在後續流程學習時大家需要特別留意一下。

Cache Aside

Cache Aside是最常見的快取模式，應用程式可直接與快取和資料庫對話。Cache Aside可用來讀操作和寫操作。

讀操作的流程圖：

讀操作的流程：

• 應用程式接收到資料查詢（讀）請求；
• 應用程式所需查詢的資料是否在快取上：
• 如果存在（Cache hit），從快取上查詢出資料，直接返回；
• 如果不存在（Cache miss），則從資料庫中檢索資料，並存入快取中，返回結果資料；

這裡我們需要留意一個操作的邊界，也就是資料庫和快取的操作均由應用程式直接進行操作。

寫操作的流程圖：

這裡的寫操作，包括建立、更新和刪除。在寫操作的時候，Cache Aside模式是先更新資料庫（增、刪、改），然後直接刪除快取。

Cache Aside模式可以說適用於大多數的場景，通常為了應對不同型別的資料，還可以有兩種策略來載入快取：

• 使用時載入快取：當需要使用快取資料時，從資料庫中查詢出來，第一次查詢之後，後續請求從快取中獲得資料；
• 預載入快取：在專案啟動時或啟動後透過程式預載入快取資訊，比如”國家資訊、貨幣資訊、使用者資訊，新聞資訊“等不是經常變更的資料。

Cache Aside適用於讀多寫少的場景，比如使用者資訊、新聞報導等，一旦寫入快取，幾乎不會進行修改。該模式的缺點是可能會出現快取和資料庫雙寫不一致的情況。

Cache Aside也是一個標準的模式，像Facebook便是採用的這種模式。

Read Through

Read-Through和Cache-Aside很相似，不同點在於程式不需要關注從哪裡讀取資料（快取還是資料庫），它只需要從快取中讀資料。而快取中的資料從哪裡來是由快取決定的。

Cache Aside是由呼叫方負責把資料載入入快取，而Read Through則用快取服務自己來載入，從而對應用方是透明的。Read-Through的優勢是讓程式程式碼變得更簡潔。

這裡就涉及到我們上面所說的應用程式操作邊界問題了，直接來看流程圖：

在上述流程圖中，重點關注一下虛線框內的操作，這部分操作不再由應用程式來處理，而是由快取自己來處理。也就是說，當應用從快取中查詢某條資料時，如果資料不存在則由快取來完成資料的載入，最後再由快取返回資料結果給應用程式。

Write Through

在Cache Aside中，應用程式需要維護兩個資料儲存：一個快取，一個資料庫。這對於應用程式來說，有一些繁瑣。

Write-Through模式下，所有的寫操作都經過快取，每次向快取中寫資料時，快取會把資料持久化到對應的資料庫中去，且這兩個操作在一個事務中完成。因此，只有兩次都寫成功了才是最終寫成功了。壞處是有寫延遲，好處是保證了資料的一致性。

可以理解為，應用程式認為後端就是一個單一的儲存，而儲存自身維護自己的Cache。

因為程式只和快取互動，編碼會變得更加簡單和整潔，當需要在多處複用相同邏輯時這點就變得格外明顯。

當使用Write-Through時，一般都配合使用Read-Through來使用。Write-Through的潛在使用場景是銀行系統。

Write-Through適用情況有：

• 需要頻繁讀取相同資料
• 不能忍受資料丟失（相對Write-Behind而言）和資料不一致

在使用Write-Through時要特別注意的是快取的有效性管理，否則會導致大量的快取佔用記憶體資源。甚至有效的快取資料被無效的快取資料給清除掉。

Write-Behind

Write-Behind和Write-Through在”程式只和快取互動且只能透過快取寫資料“這方面很相似。不同點在於Write-Through會把資料立即寫入資料庫中，而Write-Behind會在一段時間之後（或是被其他方式觸發）把資料一起寫入資料庫，這個非同步寫操作是Write-Behind的最大特點。

資料庫寫操作可以用不同的方式完成，其中一個方式就是收集所有的寫操作並在某一時間點（比如資料庫負載低的時候）批次寫入。另一種方式就是合併幾個寫操作成為一個小批次操作，接著快取收集寫操作一起批次寫入。

非同步寫操作極大地降低了請求延遲並減輕了資料庫的負擔。同時也放大了資料不一致的。比如有人此時直接從資料庫中查詢資料，但是更新的資料還未被寫入資料庫，此時查詢到的資料就不是最新的資料。

小結

不同的快取模式有不同的考量點和特徵，根據應用程式需求場景的不同，需要靈活的選擇適配的快取模式。在實踐的過程中往往也是多種模式相結合來使用。