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

今天翻譯一篇關於緩存策略的文章，原文標題是Cacheing Strategies and How to Choose the Right One，朋友推薦看的，以爲總結的不錯，鑑於不少朋友都懶得看英文的，因此皮皮就用蹩腳的水平試着翻譯一波，如何以爲還湊合，能夠幫忙轉發一下讓更多的人看到。

緩存是提升系統性能的最簡單方法之一。相對而言，數據庫（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很是類似，但至少有兩個關鍵區別:

1. 在cache-aside中，應用程序負責從數據庫中獲取數據並填充緩存。在read-through中，此邏輯一般由庫或獨立緩存提供程序支持。

2. 與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(訪問寫入數據的頻率較低)，那麼緩存中就會有無用的垃圾。能夠說，若是緩存足夠大，它可能沒問題。但在許多實際的高吞吐量系統中，當內存永遠不夠大而且須要考慮服務器成本時，正確的策略很重要。