併發環境下，先運算元據庫還是先操作快取？

來源：撿田螺的小男孩

大家好，我是田螺。在分散式系統中，快取和資料庫同時存在時，如果有寫操作的時候，先運算元據庫還是先操作快取呢？先思考一下，可能會存在哪些問題，再往下看。下面我分幾種方案闡述。

快取維護方案一

假設有一寫（執行緒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資料才刪除快取