緩存維護方案一
如果是一讀（線程B）一寫（線程A）操作，「先操作緩存，再操作數據庫」。流程圖如下所示：
-
1.線程A發起一個寫操作，第一步del cache
-
2.線程A第二步寫入新數據到DB
-
3.線程B發起一個讀操作，cache miss緩存失效了。
-
4.線程B從DB獲取最新數據
-
5.線程B執行set cache，把從DB讀到的數據，更新到緩存。
「這樣看，沒啥問題」。我們再看第二個流程圖，如下：
-
1.線程A發起一個寫操作，第一步del cache
-
2.此時線程B發起一個讀操作，cache miss
-
3.線程B繼續讀DB，讀出來一個老數據
-
4.然后老數據設置入cache
-
5.線程A寫入DB最新的數據
OK，醬紫，就有問題了吧，老數據入到緩存了，「每次讀都是老數據啦，緩存與數據與數據庫數據不一致了」。
緩存維護方案二
上個方案是一讀一寫，如果是雙寫操作，「先操作緩存，再操作數據庫」，會怎么樣呢？
-
1.線程A發起一個寫操作，第一步set cache
-
2.線程A第二步寫入新數據到DB
-
3.線程B發起一個寫操作，set cache
-
4.線程B第二步寫入新數據到DB
「這樣看，也沒啥問題。」，但是有時候可能事與愿違，我們再看第二個流程圖，如下:
-
1.線程A發起一個寫操作，第一步set cache
-
2.線程B發起一個寫操作，第一步set cache
-
3.線程B寫入數據庫到DB
-
4.線程A寫入數據庫到DB
執行完后，緩存保存的是B操作后的數據，數據庫是A操作后的數據，「緩存和數據庫數據不一致」。
緩存維護方案三
一寫（線程A）一讀（線程B）操作，「先操作數據庫，再操作緩存」。
-
1.線程A發起一個寫操作，第一步write DB
-
2.線程A第二步del cache
-
3.線程B發起一個讀操作，cache miss
-
4.線程B從DB獲取最新數據
-
5.線程B同時set cache
「有些朋友可能認為，在第2步刪除緩存之前，線程B讀過來呢？這時候，讀到的是緩存老數據，這個可以認為是正常業務邏輯呀，下次再讀取就是正確數據了。」
這種方案**「沒有明顯的并發問題」，但是有可能「步驟二刪除緩存失敗」，雖然概率比較小，「優于方案一和方案二」**，平時工作中也是使用方案三。
綜上對比，我們一般采用方案三，但是有沒有完美全解決方案三的弊端的方法呢？
緩存維護方案四
這個是方案三的改進方案，都是先操作數據庫再操作緩存，我們來看一下流程圖：
通過數據庫的**「binlog」來「異步淘汰key」，以mysql為例 可以「使用阿里的canal將binlog日志采集發送到MQ隊列」里面，然后「通過ACK機制 確認處理」** 這條更新消息，刪除緩存，保證數據緩存一致性。
但是呢還有個問題，「如果是主從數據庫呢」？
緩存維護方案五
主從DB問題：因為主從DB同步存在延時時間。如果刪除緩存之后，數據同步到備庫之前已經有請求過來時，「會從備庫中讀到臟數據」，如何解決呢？解決方案如下流程圖：
緩存維護總結
綜上所述，在分布式系統中，緩存和數據庫同時存在時，如果有寫操作的時候，「先操作數據庫，再操作緩存」。如下：
- 1.讀取緩存中是否有相關數據
- 2.如果緩存中有相關數據value，則返回
- 3.如果緩存中沒有相關數據，則從數據庫讀取相關數據放入緩存中key->value，再返回
- 4.如果有更新數據，則先更新數據庫，再刪除緩存
- 5.為了保證第四步刪除緩存成功，使用binlog異步刪除
- 6.如果是主從數據庫，binglog取自于從庫
- 7.如果是一主多從，每個從庫都要采集binlog，然后消費端收到最后一臺binlog數據才刪除緩存
最后
作為過來人，小編是整理了很多進階架構視頻資料、面試文檔以及PDF的學習資料，針對上面一套系統大綱小編也有對應的相關進階架構視頻資料，如果**‘你’確定好自己未來的道路或者想學習提升自己技術棧、技術知識的小伙伴們可以點擊這里來獲取免費學習資料提升自己（全套面試文檔、PDF、進階架構視頻）**
va-p7)提升自己（全套面試文檔、PDF、進階架構視頻）**
[外鏈圖片轉存中…(img-uMgL2rKO-1626688897205)]
[外鏈圖片轉存中…(img-carA01Nh-1626688897205)]
