1、不推薦更新快取 建議刪除快取
2、採用延時雙刪
先刪快取，
後更新資料庫，
延時再刪一次快取
但是會存在問題：改庫後延時時間內的資料可能是舊資料
如果業務場景要求，改庫成功就不能使用舊資料，可以採用如下優化方案：
新增乙個快取型別，記錄key是否被更新過，並且設定自動過期時間
在訪問的時候，先查詢key是否被更新過，如果沒有 查從庫，如果有，查主庫
3、延時雙刪第二次刪除失敗了怎麼辦
方案一：
業務**增加重試邏輯
方案二：
利用資料庫binlog，單獨的服務來處理二次刪除的邏輯，既能保證主線程的吞吐量，又能最終保證刪除成功
（1）更新資料庫資料
（2）資料庫會將操作資訊寫入binlog日誌當中
（3）訂閱程式提取出所需要的資料以及key
（4）另起一段非業務**，獲得該資訊
（5）嘗試刪除快取操作，發現刪除失敗
（6）將這些資訊傳送至訊息佇列
（7）重新從訊息佇列中獲得該資料，重試操作。
快取與資料庫資料一致性
1 無論是雙寫模式還是失效模式，都會導致快取的不一致問題。即多個例項同時更新會出事。怎麼辦？解決方案 a 如果是使用者緯度資料 訂單資料 使用者資料 這種併發機率非常小，不用考慮這個問題，快取資料加上過期時間，每隔一段時間觸發讀的主動更新即可 b 如果是選單，商品介紹等基礎資料，也可以去使用cana...
Redis快取與資料庫資料一致性
寫流程 先刪除快取，刪除之後再更新db，再非同步將資料刷回快取。如果先更新資料庫再更新快取，更新資料庫時，程式訪問快取時還是舊的資料。讀流程 先讀快取，如果快取沒讀到，則去讀db，之後再非同步將資料刷回快取。缺點 容災不足 第一步del快取失敗 如果繼續執行，那麼從 更新完db 到非同步 重新整理快...
資料一致性
資料一致性通常指關聯資料之間的邏輯關係是否正確和完整。而資料儲存的一致性模型則可以認為是儲存系統和資料使用者之間的一種約定。如果使用者遵循這種約定，則可以得到系統所承諾的訪問結果。常用的一致性模型有 a 嚴格一致性 linearizability,strict atomic consistency ...