快取使用過程中的五種策略總結及優缺點組合分析

• • 概述
  • 常用快取策略
  • • 第一種：Cache-Aside
    • 第二種：Read-Though Cache
    • 第三種：Write-Through Cache
    • 第四種 Write-Around
    • 第五種 Write-Back
  • 總結

概述

快取是提高系統性能的最簡單方法之一。相對而言，資料庫（or NoSQL資料庫）的速度比較慢，而速度卻往往又是制勝的關鍵。

如果使用得當，快取可以減少相應時間、減少資料庫負載以及節省成本。本文羅列了幾種快取策略，選擇正確的一種會有很大的不同。

快取策略取決於資料和資料訪問模式。換句話說，資料是如何寫和讀的。例如:

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

選擇正確的快取策略是提高效能的關鍵。讓我們快速瞭解一下各種快取策略。

常用快取策略

第一種：Cache-Aside

這可能是最常用的快取方法。快取位於一邊，應用程式直接與快取和資料庫對話。

簡要解釋一下:

1. 應用程式首先檢查快取。
2. 如果在快取中找到，表示已經命中快取。資料被讀取並返回給應用程式。
3. 如果在快取中沒有找到，則未命中快取。應用程式必須做一些額外的工作，它需要查詢資料庫來讀取資料，將資料返回給客戶端，然後還要將資料儲存在快取中，這樣對相同資料的後續讀取可以命中快取。

Cache-aside策略特別適合讀多的應用場景。

使用Cache-aside的系統對快取失效具有一定的彈性。如果快取叢集宕機，系統仍然可以通過直接訪問資料庫進行操作。

(不過，如果快取在峰值負載期間下降，這也沒有多大幫助。響應時間可能會變得很糟糕，最糟糕的情況是，資料庫可能會停止工作。)

另一個優點在於快取中的資料模型可以與資料庫中的資料模型不同。例如，多個查詢產生的響應可以儲存在某個請求id上。

當使用cache-aside時，最常見的寫策略是直接將資料寫到資料庫中。當這種情況發生時，快取可能與資料庫不一致。

為了解決這個問題，開發人員通常會引入TTL，並繼續提供陳舊的資料，直到TTL過期。如果必須保證資料的新鮮度，開發人員要麼使快取條目無效，要麼使用適當的寫策略，我們將在後面討論。

第二種：Read-Though Cache

Read-though策略下的快取與資料庫保持一致。當快取丟失時，它從資料庫載入相應的資料，填充快取並將其返回給應用程式（參考下圖）。

cache-aside和read-through策略都是延遲載入資料的，也就是說，只在第一次讀取資料時才載入資料。

雖然read-through和cache-aside非常相似，但至少有兩個關鍵區別:

在cache-aside中，應用程式負責從資料庫中獲取資料並填充快取。在read-through中，此邏輯通常由庫或獨立快取提供程式支援。
與cache-aside不同，read-through cache中的資料模型不能與資料庫中的資料模型不同。
當多次請求相同的資料時，**read-through快取最適合於讀量較大的工作負載。

例如，一個新聞故事。缺點是，當第一次請求資料時，它總是導致快取丟失，並導致額外的資料載入到快取的代價。

開發人員通過手動發出查詢來“預熱”或“預熱”快取來處理這個問題。就像cache-aside一樣，資料也可能在快取和資料庫之間變得不一致，而解決方案就在寫策略中，我們將在接下來看到這一點。

第三種：Write-Through Cache

在這種寫策略中，首先將資料寫入快取，然後寫入資料庫。快取與資料庫保持一致，寫操作總是通過快取到達主資料庫。

在這種寫策略中，首先將資料寫入快取，然後寫入資料庫。快取與資料庫保持一致，寫操作總是通過快取到達主資料庫。

就其本身而言，write-through快取似乎沒有多大作用，實際上，它們引入了額外的寫延遲，因為資料先寫到快取，然後寫到主資料庫。

但是，當與read-through結合使用時，我們獲得了read-through的所有好處，還獲得了資料一致性保證，使我們不必使用快取失效技術。

DynamoDB Accelerator (DAX)是write-through / read-through cache的一個很好的例子。它與DynamoDB和應用程式內聯。

對DynamoDB的讀寫可以通過DAX完成。(附註：如果您計劃使用DAX，請確保熟悉它的資料一致性模型以及它如何與DynamoDB互動。)

第四種 Write-Around

這種策略下，資料直接寫入資料庫，只有讀取的資料才能進入快取。Write-around可以與read-through結合使用，並在資料只寫一次、讀取次數較少或從不讀的情況下提供良好的效能。

例如，實時日誌或聊天室訊息。同樣，這個模式也可以與cache-aside組合使用。

第五種 Write-Back

這種策略下，應用程式將資料寫入快取，快取會立即確認，並在延遲一段時間後將資料寫入資料庫。有時這種策略也被稱為write-behind。

Write-back快取提高了寫效能，對於寫工作量大的工作負載非常有用。當與read-through相結合的時候，它對於混合工作負載非常有效，最近更新和訪問的資料總是在快取中可用。

它對資料庫故障具有很大程度上的彈性，可以容忍一些資料庫的宕機。如果支援批處理或合併，則可以減少對資料庫的總體寫操作，這將減少負載並降低成本。

一些開發人員使用Redis時，同時採用了cache-aside和write-back兩種策略，以便更好地吸收峰值負載期間的峰值。主要缺點是，如果快取失效，資料可能會永久丟失。

大多數關係資料庫儲存引擎(例如InnoDB)的內部都預設啟用了回寫快取。查詢首先寫入記憶體，最後重新整理到磁碟。

總結

在本文中，我們探討了不同的快取策略及其優缺點。在實踐中，請仔細評估您的目標，理解資料訪問(讀/寫)模式，並選擇最佳策略或組合策略。

如果你選錯了怎麼辦?一個與你的目標或訪問模式不匹配的?您可能會引入額外的延遲，或者至少沒有看到全部的好處。

例如，如果在實際應該使用write-around/read-through時選擇write-through/read-through(訪問寫入資料的頻率較低)，那麼快取中就會有無用的垃圾。

可以說，如果快取足夠大，它可能沒問題。但在許多實際的高吞吐量系統中，當記憶體永遠不夠大並且需要考慮伺服器成本時，正確的策略很重要。