淺析緩存的讀寫策略

前言

提起緩存，我們首先想到緩存是一種存儲數據的組件，它的作用是讓對數據的請求能更快地返回。

我們一般會把不經常改變而且又需要快速訪問的數據進行緩存，常用的做法是將這些數據寫進內存中，當需要訪問的時候能快速地返回需要的結果。

實際上，凡是速度相差較大的兩種硬件之間，用於協調兩者數據傳輸差异的結構，都可以稱為緩存。

在日常開發過程中，我們就經常將數據放在的本地緩存（escache）或者外部緩存（Redis）中。

緩存的讀寫策略

緩存聽起來很簡單，無非就是優先讀緩存，緩存不命中就從數據庫中查詢，查詢到了再寫回緩存。但實際上，根據不同業務場景，緩存的讀寫策略也是不同。我們就以最常見的緩存+數據庫的場景來分析。

Cache Aside（旁路緩存）策略

Cache Aside是我們使用最多的策略，緩存不和數據庫直接進行交互，而是由應用程序來同時和緩存以及數據庫打交道。Cache Aside的名字正體現了這個模式，Cache在應用的一旁(aside)。

讀數據時

1. 程序需要判斷緩存中是否已經存在數據
2. 當緩存中已經存在數據(也就是緩存命中，cache hit)，則直接從緩存中返回數據
3. 當緩存中不存在數據(也就是緩存未命中，cache miss)，則先從數據庫裏讀取數據，並且存入緩存，然後返回數據

寫數據時

1. 先更新數據庫
2. 再删除緩存中對應的數據

Read-Write Through （讀寫穿透）策略

Read/Write Through Pattern中服務端把緩存視為主要數據存儲，從中讀取數據並將數據寫入其中。緩存服務負責將此數據讀取和寫入 DB，從而减輕了應用程序的職責。

讀數據時 (Read Through)

1. 從緩存中讀取數據，讀取到就直接返回 。
2. 讀取不到的話，則由緩存組件先從數據庫加載，寫入到緩存後返回響應。
   

寫數據時 （Write Through）

1. 先查緩存，緩存中不存在，直接更新數據庫。
2. 緩存命中，則先更新緩存，然後緩存服務自己更新數據庫（同步更新緩存和數據庫）
   

在 Cache Aside下，發生讀請求的時候，如果 cache 中不存在對應的數據，是由客戶端自己負責把數據寫入 cache，而 Read-Through策略則是緩存服務自己來寫入緩存的，這對客戶端是透明的。

Read/Write Through策略的特點是由緩存節點而非用戶來和數據庫打交道，在我們開發過程中，這種策略比較少使用，原因在於我們一般使用的緩存組件（Redis或者Memcached）都不提供寫入數據庫的功能。只有本地緩存Guava Cache中的Loading Cache有Read Through策略的影子。

可以看出，由於Write Through寫數據時需要同時更新數據庫，對於性能會有比較大的影響。那麼我們可不可以异步更新數據庫呢？這就是接下來的Write Back策略。

Write-Back（异步緩存寫入）策略

Write-Back策略和Read-Write Through策略的共同點在於兩者都是由緩存服務來負責緩存和數據庫的讀寫。

不同點在於Write-Back將緩存作為可靠的數據源，每次都只寫入緩存，而寫入數據庫則采用异步的方式，比如當數據要被移除出緩存的時候再存儲到數據庫或者一段時間之後批量更新數據庫。

優點：在於讀寫速度非常快，因為都是從緩存中直接讀取和寫入。對於服務中數據庫不可用有一定的容忍度，當數據庫不可用時，也能正常處理結果，待數據庫恢複後再重新更新數據。同時也降低了數據庫壓力，寫數據庫操作可以放在業務流量較低的時候進行。

缺點：有數據丟失的風險，如果緩存服務掛掉而數據沒有及時寫入數據庫中，則數據會丟失。

適合場景： 數據經常變化又對數據一致性要求沒那麼高的場景，比如瀏覽量、點贊量

總結

這三種緩存讀寫策略各有優劣，需要我們根據具體的業務場景選擇更適合的。如果讀多寫少，且對於數據一致性要求高，可以使用Cache Aside策略。如果寫多讀少，且對於數據一致性要求不高，可以Read-Write Through或者Write-Back策略。

Ryan.ou