前言
在分佈式系統中，緩存和數據庫同時存在時，如果有寫操作的時候，先操作數據庫還是先操作緩存呢？
先思考一下，可能會存在哪些問題，再往下看。下面我分幾種方案闡述。
緩存維護方案一
假設有一寫（線程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數據才刪除緩存