快取資料庫雙寫不一致怎麼解決
前言
在實際的專案開發中，為了提高響應的速度，通常都會將熱點的資料儲存到快取中，減少資料庫的查詢，有效提高服務端的響應速度，但是新增快取之後也引入快取與資料庫的一致性問題，本文將詳細的講解如何保證資料庫與快取的一致性。
快取使用策略
在使用快取時，通常的快取冊率有如下幾種：
Cache-Aside Pattern（旁路快取，業務系統常用）
Read-Through Pattern
Write-Through Pattern
Write-Behind Pattern
Cache-Aside Pattern（旁路快取模式）
Cache-Aside Pattern 簡稱旁路快取模式，讀取快取、讀取資料庫和更新快取的操作都是在應用系統中完成，也是業務系統最常用的快取策略。然而旁路路由策略又分為讀快取和寫快取。
讀快取
說明：
應用程式需要從資料庫讀取資料時，先檢查快取資料是否命中。
如果快取未命中，則查詢資料庫獲取資料，同時將資料寫到快取中，以便後續讀取相同資料會命中快取，最後再把資料返回給呼叫者。
如果快取命中，直接返回呼叫者。
寫快取
寫快取的流程就比較簡單，先更新資料庫中的資料，然後刪除舊的快取即可。
Cache-Aside Pattern 一致性問題場景分析
實際的專案中運用最多的為Cache-Aside Pattern（旁路快取）模式，在此策略下客戶端先讀取快取，如果命中則返回，如果沒有命中，則查詢資料庫併發資料寫入快取，由於資料庫和快取都需要進行修改，在高併發的場景下，可能會導致資料不一致，針對資料不一致的場景，提供了四種更新方案具體如下：
先更新快取，再更新資料庫。
先更新資料庫，再更新快取。
先刪除快取，再更新資料庫。
先更新資料庫，再刪除快取。
接下來具體來講解四種方案的，以及四種方案存在的問題。
先更新快取，再更新資料庫。
流程說明： 執行緒1：先更新快取成功，但是網路原因寫資料庫失敗，就會導致快取是最新資料，而資料庫的資料為舊資料，那快取就是髒資料， 執行緒2：讀取快取中資料，而這個資料資料庫中卻不存在，資料庫都不存在的資料，快取並返回客戶端就毫無意義了。
此方案在實際生產中不建議採用。
先更新資料庫，再更新快取。
流程說明：
執行緒1先更新資料庫成功，但是由於網路卡頓更新快取失敗，從而導致快取中的資料為舊資料
執行緒2從快取中讀取資料，快取中的資料為舊數，從而導致資料庫與快取資料不一致。
此方案在實際生產中不建議採用。
先刪除快取，再更新資料庫。
流程說明：
執行緒1，先刪除快取成功，但是由於網路卡頓原因，更新資料庫異常。
執行緒2，讀取快取由於快取資料為空，則會查詢資料庫中的資料，查詢成功並寫入快取，從而導致資料不一致。
此方案在實際生產中不建議採用。
先更新資料庫，再刪除快取。
流程說明：
執行緒1寫入資料庫成功，由於網路卡頓原因，導致刪除快取資料失敗
執行緒2讀取資料，讀取為快取中的資料，但是當網路恢復正常後，快取中的資料會被刪除，所以可能會存在短暫的資料不一致。
雖然存在短暫的資料不一致，但是在旁路快取策略的時候，對於寫的操作：先更新資料庫，再刪除快取。
資料庫和快取一致性解決方案
快取延遲雙刪
快取延遲雙刪針對第三種場景的最佳化，具體的流程如下：
說明：先刪除快取，在更新資料庫，確保資料庫事務提交成功，然後休眠一段時間在刪除快取。我們都知道第三種情況是因為網路卡頓導致資料庫更新失敗，當網路恢復正常後，我們在執行更新資料庫操作，然後再刪除快取，那麼出現數據不一致的情況也就是在休眠的這短暫的時間內。
刪除快取失敗如何處理
刪除快取重試機制
需要刪除失敗的key存入訊息佇列中，採用非同步的方式來進行刪除，如果刪除失敗的次數已經超過了最大次數，傳送警告郵件，需要人工介入解決。
總結
本文對於資料庫和快取的一致性進行詳細的講解，由於資料庫和快取一致性的場景比較複雜，每種方案都無法保證絕對的一致性，根據CAP理論我們知道快取系統使用場景為非強一致性的場景，符合CAP中的AP，如有疑問請及時反饋。
作者：劍聖無痕
連結：
https：//juejin。cn/post/7126188464713760776