?

?

歡迎跳轉到本文的原文鏈接：https://honeypps.com/cache/cache-strategy-and-relative-merits-analysis/

?

今天翻譯一篇關于緩存策略的文章，原文標題是Cacheing Strategies and How to Choose the Right One，同事推薦看的，覺得總結的不錯，鑒于很多同學都懶得看英文的，所以皮皮就用蹩腳的水平試著翻譯一波，如何覺得還湊合，記得點個“在看”，^-^。

緩存是提高系統性能的最簡單方法之一。相對而言，數據庫（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(訪問寫入數據的頻率較低)，那么緩存中就會有無用的垃圾。可以說，如果緩存足夠大，它可能沒問題。但在許多實際的高吞吐量系統中，當內存永遠不夠大并且需要考慮服務器成本時，正確的策略很重要。

希望你喜歡這篇文章。請在下面的評論部分告訴我，您在項目中使用了哪種緩存策略。

原文：https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/
作者：Umer Mansoor
譯者：朱小廝的博客

?

---

歡迎跳轉到本文的原文鏈接：https://honeypps.com/cache/cache-strategy-and-relative-merits-analysis/

想知道更多？掃描下面的二維碼關注我

相關推薦：

• 《科普 | 明星公司之Netflix》

• 《看我如何作死 | 將CPU、IO打爆》

• 《看我如何作死 | 網絡延遲、丟包、中斷一個都沒落下》

• 《7102-2019年技術文全套整理，建議收藏》

• 《看我如何假死！》

?

>>>Learn More<<

?

點個"在看"唄^_^

總結

以上是生活随笔為你收集整理的总结缓存使用过程中的几种策略以及优缺点组合分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。