為了減少資料不一致的情況，更新快取和資料庫的機制顯得特別重要，接下來帶領大家踩到坑。
#Cache aside也就是旁路快取，是比較常用的快取策略。
（1）讀取請求常見流程
應用程式首先會判斷快取是否有該數據，快取命中直接返回數據，快取未命中即快取穿透到資料庫，從資料庫查詢資料然後回寫到快取中，最後返回資料給客戶端。
（2）寫入請求常見流程
看了寫請求的圖表之後，有些同學可能要問了：為什麼要刪除緩存，直接更新不就行了？這裡涉及到幾個坑，我們一步一步地踩下去。
Cache aside踩坑
如果同時有兩個
寫入請求需要更新數據，每個寫入請求都先更新資料庫再更新緩存，在並發場景可能會出現資料不一致的情況。
先更新資料庫，再更新快取
（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）速度非常快，通常會在更新資料庫之前完成。
如果這種極端場景出現了怎麼辦？我們得想一個兜底的辦法：快取資料設定過期時間。通常在系統中是可以允許少量的資料短時間不一致的場景出現。
在 Cache Aside 更新模式中，應用程式碼需要維護兩個資料來源：一個是緩存，一個是資料庫。而在 Read-Through 政策下，應用程式無需管理快取和資料庫，只需要將資料庫的同步委託給快取提供者 Cache Provider 即可。所有資料互動都是透過抽象的快取層完成。
如上圖，應用程式只需要與Cache Provider交互，不用關心是從緩存取還是資料庫.
在進行大量讀取時，Read-Through 可以減少資料來源上的負載，也對快取服務的故障具備一定的彈性。如果快取服務掛了，則快取提供者仍然可以透過直接轉到資料來源來進行操作。
Read-Through 適用於多次要求相同資料的場景，這與 Cache-Aside 策略非常相似，但是二者還是存在一些差別，這裡再次強調一下：
Write-Through 策略下，當發生資料更新(Write)時，快取提供程序Cache Provider 負責更新底層資料來源和快取。
快取與資料來源保持一致，並且寫入時始終透過抽象快取層到達資料來源。
Cache Provider類似一個代理人的作用。
Write behind在某些地方也被成為Write back， 簡單理解就是：應用程式更新資料時只更新緩存， Cache Provider每隔一段時間將資料刷新到資料庫中。說穿了就是延遲寫入。
如上圖，應用程式更新兩個數據，Cache Provider 會立即寫入快取中，但是隔一段時間才會批次寫入資料庫中。
這種方式有優點也有缺點：
#優點是資料寫入速度非常快，適用於頻繁寫的場景。
缺點是快取和資料庫不是強一致性，對一致性要求高的系統慎用。
學了這麼多，相信大家對快取更新的策略都已經有了清晰的認識。最後稍稍總結一下。
快取更新的策略主要分為三種：
Cache aside 通常會先更新資料庫，然後刪除緩存，為了兜底通常也會將資料設定快取時間。
Read/Write through 一般是由一個 Cache Provider 對外提供讀寫操作，應用程式不用感知操作的是快取還是資料庫。
Write behind簡單理解就是延遲寫入，Cache Provider 每隔一段時間就會批次輸入資料庫，優點是應用程式寫入速度非常快。
好了，今天先到這裡了，大家學會了嗎？
以上是高並發場景下，到底先更新快取還是先更新資料庫？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
