併發環境下,先操作資料庫還是先操作快取?
前言
在分散式系統中,快取和資料庫同時存在時,如果有寫操作的時候,先操作資料庫還是先操作快取呢?先思考一下,可能會存在哪些問題,再往下看。下面我分幾種方案闡述。
快取維護方案一
假設有一寫(執行緒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資料才刪除快取
個人公眾號
歡迎大家關注,大家一起學習,一起討論哈