緩存使用過程中的五種策略總結及優缺點

概述

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

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

緩存策略取決於數據和數據訪問模式。換句話說，數據是如何寫和讀的。例如:

系統是寫多讀少的嗎？(例如基於時間的日誌)
數據是否是隻寫入一次並被讀取多次?(例如用戶配置文件)
返回的數據總是惟一的嗎?(例如搜索查詢)

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

常用緩存策略

第一種：Cache-Aside

這可能是最常用的緩存方法。緩存位於一邊，應用程序直接與緩存和數據庫對話。

簡要解釋一下:

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

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(訪問寫入數據的頻率較低)，那麼緩存中就會有無用的垃圾。

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

緩存使用過程中的五種策略總結及優缺點