併發環境下，先操作資料庫還是先操作快取？
前言
在分散式系統中，快取和資料庫同時存在時，如果有寫操作，先操作資料庫還是先操作快取呢？本文將分5種方案展開闡述對比，謝謝閱讀~
github地址，衷心感謝每一顆star
❝
https://github.com/whx123/JavaHome
❞快取維護方案一
如果是一讀（執行緒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，獲得電子書學習