一文帶你搞懂「緩存策略」

本文由 yanglbme 原創，首發於公衆號「Doocs開源社區」，歡迎轉載。

咱們都知道，提升系統性能的最簡單也最流行的方法之一其實就是使用緩存。咱們引入緩存，至關於對數據進行了複製。每當系統數據更新時，保持緩存和數據源（如 MySQL 數據庫）同步相當重要，固然，這也取決於系統自己的要求，看系統是否容許必定的數據延遲。

在這篇文章裏，我想給大家介紹最多見的幾種緩存策略、它們的優缺點以及使用場景，分別是：

• Cache-Aside
• Read-Through
• Write-Through
• Write-Behind

請跟隨我一塊兒來看看吧。

Cache-Aside 策略

Cache-Aside 多是最經常使用的緩存策略。在這種策略下，應用程序(Application)會與緩存(Cache)和數據源(Data Source)進行通訊，應用程序會在命中數據源以前先檢查緩存。以下圖所示：

咱們來看一次請求數據的過程：

• 首先，應用程序先肯定數據是否保留在緩存中；
• 若是數據在緩存中，也即 Cache hit ，稱做「緩存命中」。數據直接從緩存中讀取並返回給客戶端應用程序；
• 若是數據不在緩存中，也即 Cache miss，稱做「緩存未命中」。應用程序會從數據存儲的地方，如 MySQL 數據源中讀取該數據，並將數據存儲在緩存中，而後將其返回給客戶端。

Cache-Aside 策略特別適合「讀多」的應用場景。使用 Cache Aside 策略的系統能夠在必定程度上抵抗緩存故障。若是緩存服務發生故障，系統仍然能夠經過直接訪問數據庫進行操做。

然而，這種策略並不能保證數據存儲和緩存之間的一致性，須要配合使用其它策略來更新或使緩存無效。另外，首次請求數據時，老是會致使緩存未命中，這種狀況下須要額外的時間來將數據加載到緩存中。爲了解決這個問題，開發人員能夠經過手動觸發查詢操做來對數據進行「預熱」。

Read-Through 策略

在上面的 Cache-Aside 策略中，應用程序須要與緩存和數據源「打交道」，而在 Read-Through 策略下，應用程序無需管理數據源和緩存，只須要將數據源的同步委託給緩存提供程序 Cache Provider 便可。全部數據交互都是經過抽象緩存層完成的。

在進行大量讀取時，Read-Through 能夠減小數據源上的負載，也對緩存服務的故障具有必定的彈性。若是緩存服務掛了，則緩存提供程序仍然能夠經過直接轉到數據源來進行操做。

然而，首次請求數據時，老是會致使緩存未命中，並須要額外的時間來將數據加載到緩存中，相信你們都知道怎麼處理了吧，仍是「緩存預熱」的老套路。

Read-Through 適用於屢次請求相同數據的場景。這與 Cache-Aside 策略很是類似，可是兩者仍是存在一些差異，這裏再次強調一下：

• 在 Cache-Aside 中，應用程序負責從數據源中獲取數據並更新到緩存。
• 而在 Read-Through 中，此邏輯一般是由獨立的緩存提供程序支持。

Write-Through 策略

Write-Through 策略下，當發生數據更新(Write)時，緩存提供程序 Cache Provider 負責更新底層數據源和緩存。緩存與數據源保持一致，而且寫入時始終經過抽象緩存層到達數據源。

實際上，因爲須要將數據同步寫入緩存和數據源，所以數據寫入速度較慢。可是，當與 Read-Through 配合使用時，咱們將得到 Read-Through 的全部好處，而且還能夠得到數據一致性保證，從而使咱們免於使用緩存失效技術。

Write-Behind 策略

若是沒有強一致性要求，咱們能夠簡單地使緩存的更新請求入隊，而且按期將其 flush 刷新到數據存儲中。

也就是說，Write-Behind 在數據更新時，只寫入緩存。優勢是數據寫入速度快，適用於繁重的寫工做負載。與 Read-Through 配合使用，能夠很好地用於混合工做負載，最近更新和訪問的數據老是在緩存中可用。

它能夠抵抗數據源故障，並能夠容忍某些數據源停機時間。若是支持批處理或合併，則能夠減小對數據源的整體寫入，從而減小了負載並下降了成本。

可是，一旦更新後的緩存數據還未被寫入數據源時，出現系統斷電的狀況，數據將沒法找回。

怎麼樣，是否是對緩存策略有了進一步認識？