深入淺出快取策略 (Cache Strategy)

發表於 2025-08-23 分類於技術筆記

在日常開發中，總會遇到一個共同的挑戰：如何讓應用程式反應更快、處理更多請求，同時又不會讓資料庫不堪重負？

答案往往指向一個強大的技術：快取 (Caching)。

然而，快取並不是一個簡單的「啟用/停用」開關。要真正發揮它的威力，需要理解並選擇正確的快取策略 (Cache Strategy)。這篇文章將深入淺出地探索幾種核心的快取策略，幫助應用程式做出最佳選擇。

為什麼需要快取策略？

想像一下，書桌就是快取 (Cache)，而身後巨大的書櫃則是資料庫 (Database)。

當需要一本書（資料）時，如果它就在書桌上，隨手就能拿到，非常快。這就是 Cache Hit (快取命中)。如果書桌上沒有，就得轉身走到書櫃，花時間找到它，再拿回書桌。這就是 Cache Miss (快取未命中)，成本顯然高得多。

快取策略，就是決定「哪些書應該放在書桌上」以及「書本內容更新時，如何同步書桌和書櫃」的一套規則。一個好的策略能確保書桌上總有你最需要的書，而且資訊不會過時。

一個簡單的比喻：快取就像你的工作桌面，資料庫則是檔案櫃

核心快取讀寫策略

接下來，讓我們深入了解幾種最常見的讀寫策略。每種策略都有其獨特的運作模式、優缺點及適用場景。

1. Cache-Aside (旁路快取)

這是最常見、也最經典的快取策略，可能不知不覺中已經在使用它了。

核心思想：應用程式全權負責維護快取和資料庫，快取只是一個「旁路」儲存。

運作流程：

讀取 (Read):
1. 應用程式先向快取請求資料。
2. 如果快取命中 (Hit)，直接將資料返回給客戶端。
3. 如果快取未命中 (Miss)，應用程式會向資料庫請求資料。
4. 從資料庫取得資料後，先將資料寫入快取，然後再返回給客戶端。
寫入 (Write):
1. 應用程式直接更新資料庫。
2. 更新成功後，讓快取中的對應資料失效 (Invalidate)。

流程圖：

// 讀取流程
Client ---> App ---> Cache?
             |       (Miss)
             |          |
             V          V
             App ---> Database
              ^          |
              |          V
              +----- Cache (Set)

優點 (Pros):
- 邏輯簡單直觀：開發者完全掌控資料流。
- 高可用性：即使快取服務掛了，應用程式仍能從資料庫讀取資料，只是速度變慢。
- 資料庫與快取解耦：兩者可以獨立擴展和部署。
缺點 (Cons):
- 首次請求延遲：對於冷資料（第一次被請求的資料），總會發生一次 Cache Miss，延遲較高。
- 資料不一致性：在「寫入資料庫」和「讓快取失效」這兩個步驟之間，存在一個微小的時間窗口，可能導致讀到舊資料。
適用場景：
- 讀多寫少的應用場景，例如：商品目錄、新聞文章、使用者個人資料頁。
- 對資料一致性要求不是極端嚴格的系統。

2. Read-Through (讀取穿透)

這個策略將快取變成資料的主要入口，應用程式本身不用再關心資料庫。

核心思想：應用程式只跟快取打交道，由快取本身負責從資料庫載入資料。

運作流程：

讀取 (Read):
1. 應用程式向快取請求資料。
2. 如果快取命中 (Hit)，直接返回資料。
3. 如果快取未命中 (Miss)，快取服務會自己去向資料庫請求資料。
4. 快取從資料庫取得資料後，先存入自身，再返回給應用程式。

流程圖：

Client ---> App ---> Cache?
                        | (Miss)
                        V
                     Database (Loaded by Cache)

優點 (Pros):
- 簡化應用程式邏輯：應用程式的程式碼更乾淨，不用再寫快取未命中時去讀取資料庫的邏輯。
- 一致的資料來源：所有讀取請求都從同一個來源（快取）獲取。
缺點 (Cons):
- 實作複雜：通常需要快取函式庫或服務（如 Ehcache, Hazelcast）提供支援。
- 首次請求延遲：與 Cache-Aside 相同，冷資料的首次載入會比較慢。
適用場景：
- 適合那些希望將快取邏輯與業務邏輯分離的架構。
- 當使用的快取系統原生支援此模式時。

3. Write-Through (寫入穿透)

與 Read-Through 相對應，Write-Through 讓快取成為寫入操作的代理。

核心思想：應用程式的寫入操作只針對快取，由快取負責同步更新資料庫。

運作流程：

寫入 (Write):
1. 應用程式將新資料寫入快取。
2. 快取服務立即將該資料同步寫入資料庫。
3. 只有當快取和資料庫都寫入成功後，才向應用程式返回成功。

流程圖：

Client ---> App ---> Cache (Set) ---> Database (Sync Write)

優點 (Pros):
- 強資料一致性：寫入操作是同步的，快取和資料庫的資料永遠一致，不會讀到舊資料。
- 簡化應用程式邏輯：寫入邏輯統一由快取處理。
缺點 (Cons):
- 寫入延遲高：每次寫入都要等待快取和資料庫兩次 I/O 操作完成，效能較差。
- 不適合寫入頻繁的場景：會給資料庫帶來巨大壓力。
適用場景：
- 對資料一致性要求極高，且不允許丟失任何寫入的場景，例如：銀行交易、訂單狀態更新。
- 讀取頻率遠大於寫入頻率的系統。

4. Write-Back (回寫 / 延遲寫入)

這是一種高效能的寫入策略，追求極致的寫入速度。

核心思想：寫入操作只更新快取，然後在未來的某個時間點（例如：延遲一段時間、累積一定數量）才將資料「批次」寫回資料庫。

運作流程：

寫入 (Write):
1. 應用程式將新資料寫入快取。
2. 快取將該資料標記為「髒資料 (Dirty)」，並立即向應用程式返回成功。
3. 快取服務會在之後的某個時間點（例如：每隔 5 秒），將所有「髒資料」一次性寫入資料庫。

流程圖：

// Step 1: Immediate Write
Client ---> App ---> Cache (Set & Mark as Dirty)

// Step 2: Delayed Write
Cache ---> (Async Batch Write) ---> Database

優點 (Pros):
- 極低的寫入延遲：應用程式幾乎感受不到資料庫的寫入耗時，響應速度極快。
- 降低資料庫壓力：將多次零散的寫入合併為一次批次寫入，大幅提升資料庫吞吐量。
缺點 (Cons):
- 可能遺失資料：如果在快取將髒資料寫回資料庫之前，快取服務崩潰或斷電，這部分資料將會永久遺失。
- 實作複雜：需要可靠的機制來管理髒資料的寫回。
適用場景：
- 寫入極其頻繁的場景，例如：即時數據監控、使用者行為追蹤、IoT 設備數據上報。
- 可以容忍在極端情況下丟失少量最新資料的系統。

策略選擇

策略 (Strategy)	資料一致性	寫入效能	讀取效能	實作複雜度	風險
Cache-Aside	中等	高	中等	低	資料不一致
Read-Through	中等	-	中等	中等	快取依賴
Write-Through	高	低	高	中等	寫延遲
Write-Back	低	極高	高	高	資料遺失

如何選擇？問自己幾個問題：

業務能容忍多大程度的資料不一致？
- 如果完全不能容忍 -> 考慮 Write-Through。
- 如果可以稍微容忍 -> Cache-Aside 是個不錯的起點。
應用是讀多還是寫多？
- 讀多寫少 -> Cache-Aside / Read-Through 非常適合。
- 寫多讀少，且寫入效能是瓶頸 -> Write-Back 是救星。
能接受資料遺失的風險嗎？
- 絕不！ -> 遠離 Write-Back。
- 可以接受丟失幾秒鐘的非核心資料 -> Write-Back 可以大幅提升效能。

結論

快取策略是系統架構設計中的一門藝術，它關乎效能、成本和可靠性之間的精妙平衡。

Cache-Aside 是最靈活、最常見的萬金油策略。
Write-Through 提供了最強的資料一致性保證，但犧牲了寫入效能。
Write-Back 提供了極致的寫入效能，但伴隨著資料遺失的風險。

記住，最好的策略永遠是最適合當前業務場景的那一個。深入理解需求，然後勇敢地去實驗和選擇吧！