在大型系統中，為了減少數據庫壓力通常會引入緩存機制，一旦引入緩存又很容易造成緩存和數據庫數據不一致，導致用戶看到的是舊數據。
為了減少數據不一致的情況，更新緩存和數據庫的機制顯得尤為重要，接下來帶領大家踩踩坑。
Cache aside
Cache aside也就是旁路緩存，是比較常用的緩存策略。
(1)讀請求常見流程
Cache aside 讀請求
應用首先會判斷緩存是否有該數據，緩存命中直接返回數據，緩存未命中即緩存穿透到數據庫，從數據庫查詢數據然后回寫到緩存中，最后返回數據給客戶端。
(2)寫請求常見流程
Cache aside 寫請求
首先更新數據庫，然后從緩存中刪除該數據。
看了寫請求的圖之后，有些同學可能要問了：為什么要刪除緩存，直接更新不就行了?這里涉及到幾個坑，我們一步一步踩下去。
Cache aside踩坑
Cache aside策略如果用錯就會遇到深坑，下面我們來逐個踩。
踩坑一：先更新數據庫，再更新緩存
如果同時有兩個寫請求需要更新數據，每個寫請求都先更新數據庫再更新緩存，在并發場景可能會出現數據不一致的情況。
先更新數據庫，再更新緩存
如上圖的執行過程：
(1)寫請求1更新數據庫，將 age 字段更新為18;
(2)寫請求2更新數據庫，將 age 字段更新為20;
(3)寫請求2更新緩存，緩存 age 設置為20;
(4)寫請求1更新緩存，緩存 age 設置為18;
執行完預期結果是數據庫 age 為20，緩存 age 為20，結果緩存 age為18，這就造成了緩存數據不是最新的，出現了臟數據。
踩坑二：先刪緩存，再更新數據庫
如果寫請求的處理流程是先刪緩存再更新數據庫，在一個讀請求和一個寫請求并發場景下可能會出現數據不一致情況。
先刪緩存，再更新數據庫
如上圖的執行過程：
(1)寫請求刪除緩存數據;
(2)讀請求查詢緩存未擊中(Hit Miss)，緊接著查詢數據庫，將返回的數據回寫到緩存中;
(3)寫請求更新數據庫。
整個流程下來發現數據庫中age為20，緩存中age為18，緩存和數據庫數據不一致，緩存出現了臟數據。
在實際的系統中針對寫請求還是推薦先更新數據庫再刪除緩存，但是在理論上還是存在問題，以下面這個例子說明。
先更新數據庫，再刪除緩存
如上圖的執行過程：
(1)讀請求先查詢緩存，緩存未擊中，查詢數據庫返回數據;
(2)寫請求更新數據庫，刪除緩存;
(3)讀請求回寫緩存;
整個流程操作下來發現數據庫age為20，緩存age為18，即數據庫與緩存不一致，導致應用程序從緩存中讀到的數據都為舊數據。
但我們仔細想一下，上述問題發生的概率其實非常低，因為通常數據庫更新操作比內存操作耗時多出幾個數量級，上圖中最后一步回寫緩存(set age 18)速度非常快，通常會在更新數據庫之前完成。
如果這種極端場景出現了怎么辦?我們得想一個兜底的辦法：緩存數據設置過期時間。通常在系統中是可以允許少量的數據短時間不一致的場景出現。
Read through
在 Cache Aside 更新模式中，應用代碼需要維護兩個數據源頭：一個是緩存，一個是數據庫。而在 Read-Through 策略下，應用程序無需管理緩存和數據庫，只需要將數據庫的同步委托給緩存提供程序 Cache Provider 即可。所有數據交互都是通過抽象緩存層完成的。
Read-Through流程
如上圖，應用程序只需要與Cache Provider交互，不用關心是從緩存取還是數據庫。
在進行大量讀取時，Read-Through 可以減少數據源上的負載，也對緩存服務的故障具備一定的彈性。如果緩存服務掛了，則緩存提供程序仍然可以通過直接轉到數據源來進行操作。
Read-Through 適用于多次請求相同數據的場景，這與 Cache-Aside 策略非常相似，但是二者還是存在一些差別，這里再次強調一下：
在 Cache-Aside 中，應用程序負責從數據源中獲取數據并更新到緩存。
在 Read-Through 中，此邏輯通常是由獨立的緩存提供程序(Cache Provider)支持。
Write through
Write-Through 策略下，當發生數據更新(Write)時，緩存提供程序 Cache Provider 負責更新底層數據源和緩存。
緩存與數據源保持一致，并且寫入時始終通過抽象緩存層到達數據源。
Cache Provider類似一個代理的作用。
Write-Through流程
Write behind
