分佈式系統中，緩存和數據庫同時存在，若是寫操做先操做哪個？

前言

在分佈式系統中，緩存和數據庫同時存在時，若是有寫操做的時候，先操做數據庫仍是先操做緩存呢？先思考一下，可能會存在哪些問題，再往下看。下面我分幾種方案闡述。

緩存維護方案一

假設有一寫（線程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數據才刪除緩存