高併發場景下，到底先更新快取還是先更新資料庫？
在大型系統中，為了減少資料庫壓力通常會引入快取機制，一旦引入快取又很容易造成快取和資料庫資料不一致，導致使用者看到的是舊資料。為了減少資料不一致的情況，更新快取和資料庫的機制顯得尤為重要，接下來帶領大家踩踩坑。
Cache aside
Cache aside
也就是
旁路快取
，是比較常用的快取策略。
（1）讀請求常見流程
應用首先會判斷快取是否有該資料，快取命中直接返回資料，快取未命中即快取穿透到資料庫，從資料庫查詢資料然後回寫到快取中，最後返回資料給客戶端。
（2）寫請求常見流程
首先更新資料庫，然後從快取中刪除該資料。
看了寫請求的圖之後，有些同學可能要問了：為什麼要刪除快取，直接更新不就行了？這裡涉及到幾個坑，我們一步一步踩下去。
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
即可。所有資料互動都是透過
抽象快取層
完成的。
如上圖，應用程式只需要與
Cache Provider
互動，不用關心是從快取取還是資料庫。
在進行大量讀取時，
Read-Through
可以減少資料來源上的負載，也對快取服務的故障具備一定的彈性。如果快取服務掛了，則快取提供程式仍然可以透過直接轉到資料來源來進行操作。
Read-Through 適用於多次請求相同資料的場景
，這與 Cache-Aside 策略非常相似，但是二者還是存在一些差別，這裡再次強調一下：
在 Cache-Aside 中，應用程式負責從資料來源中獲取資料並更新到快取。
在 Read-Through 中，此邏輯通常是由獨立的快取提供程式（Cache Provider）支援。
Write through
Write-Through
策略下，當發生資料更新（Write）時，快取提供程式
Cache Provider
負責更新底層資料來源和快取。
快取與資料來源保持一致，並且寫入時始終透過
抽象快取層
到達資料來源。
Cache Provider
類似一個代理的作用。
Write behind
Write behind
在一些地方也被成為
Write back
， 簡單理解就是：應用程式更新資料時只更新快取，
Cache Provider
每隔一段時間將資料重新整理到資料庫中。說白了就是
延遲寫入
。
如上圖，應用程式更新兩個資料，Cache Provider 會立即寫入快取中，但是隔一段時間才會批次寫入資料庫中。
這種方式有優點也有缺點：
優點
是資料寫入速度非常快，適用於頻繁寫的場景。
缺點
是快取和資料庫不是強一致性，對一致性要求高的系統慎用。
總結一下
學了這麼多，相信大家對快取更新的策略都已經有了清晰的認識。最後稍稍總結一下。
快取更新的策略主要分為三種：
Cache aside
Read/Write through
Write behind
Cache aside 通常會先更新資料庫，然後再刪除快取，為了兜底通常還會將資料設定快取時間。
Read/Write through 一般是由一個 Cache Provider 對外提供讀寫操作，應用程式不用感知操作的是快取還是資料庫。
Write behind簡單理解就是延遲寫入，Cache Provider 每隔一段時間會批次輸入資料庫，優點是應用程式寫入速度非常快。