並發環境下，先操作資料庫還是先操作快取？
- 2019 年 10 月 3 日
- 筆記
前言
在分散式系統中，快取和資料庫同時存在時，如果有寫操作的時候，先操作資料庫還是先操作快取呢？先思考一下，可能會存在哪些問題，再往下看。下面我分幾種方案闡述。
快取維護方案一
假設有一寫（執行緒A）一讀（執行緒B）操作，先操作快取，在操作資料庫。，如下流程圖所示：
1）執行緒A發起一個寫操作，第一步del cache
2）執行緒A第二步寫入新數據到DB
3）執行緒B發起一個讀操作，cache miss，
4）執行緒B從DB獲取最新數據
5）請求B同時set cache
這樣看，沒啥問題。我們再看第二個流程圖，如下：
1）執行緒A發起一個寫操作，第一步del cache
2）此時執行緒B發起一個讀操作，cache miss
3）執行緒B繼續讀DB，讀出來一個老數據
4）然後老數據入cache
5）執行緒A寫入了最新的數據
OK，醬紫，就有問題了吧，老數據入到快取了，每次讀都是老數據啦，快取與數據與資料庫數據不一致。
快取維護方案二
雙寫操作，先操作快取，在操作資料庫。
1）執行緒A發起一個寫操作，第一步set cache
2）執行緒A第二步寫入新數據到DB
3）執行緒B發起一個寫操作，set cache，
4）執行緒B第二步寫入新數據到DB
這樣看，也沒啥問題。，但是有時候可能事與願違，我們再看第二個流程圖，如下:
1）執行緒A發起一個寫操作，第一步set cache
2）執行緒B發起一個寫操作，第一步setcache
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
這種方案沒有明顯的並發問題，但是有可能步驟二刪除快取失敗，雖然概率比較小，優於方案一和方案二，平時工作中也是使用方案三。
綜上對比，我們一般採用方案三，但是有沒有完美全解決方案三的弊端的方法呢？
快取維護方案四
這個是方案三的改進方案，都是先操作資料庫再操作快取，我們來看一下流程圖：
通過資料庫的binlog來非同步淘汰key，以mysql為例
可以使用阿里的canal將binlog日誌採集發送到MQ隊列裡面，然後通過ACK機制
確認處理 這條更新消息，刪除快取，保證數據快取一致性。
但是呢還有個問題，如果是主從資料庫呢？
快取維護方案五
主從DB問題：因為主從DB同步存在同時延時時間如果刪除快取之後，數據同步到備庫之前已經有請求過來時，會從備庫中讀到臟數據，如何解決呢？解決方案如下流程圖：
快取維護總結
綜上所述，在分散式系統中，快取和資料庫同時存在時，如果有寫操作的時候，先操作資料庫，再操作快取。如下：
（1）讀取快取中是否有相關數據
（2）如果快取中有相關數據value，則返回
（3）如果快取中沒有相關數據，則從資料庫讀取相關數據放入快取中key->value，再返回
（4）如果有更新數據，則先更新數據，再刪除快取
（5）為了保證第四步刪除快取成功，使用binlog非同步刪除
（6）如果是主從資料庫，binglog取自於從庫
（7）如果是一主多從，每個從庫都要採集binlog，然後消費端收到最後一台binlog數據才刪除快取
個人公眾號
歡迎大家關注，大家一起學習，一起討論哈。
