前言
在分布式系統中，緩存和資料庫同時存在時，如果有寫操作的時候，先操作資料庫還是先操作緩存呢？
先思考一下，可能會存在哪些問題，再往下看。下面我分幾種方案闡述。
緩存維護方案一
假設有一寫（線程A）一讀（線程B）操作，先操作緩存，在操作資料庫，如下流程圖所示
1）線程A發起一個寫操作，第一步del cache
2）線程A第二步寫入新資料到DB
3）線程B發起一個讀操作，cache miss，
4）線程B從DB擷取最新資料
5）請求B同時set cache
這樣看，沒啥問題。我們再看第二個流程圖，如下：
2）此時線程B發起一個讀操作，cache miss
3）線程B繼續讀DB，讀出來一個老資料
4）然後老資料入cache
5）線程A寫入了最新的資料
OK，醬紫，就有問題了吧，老資料入到緩存了，每次讀都是老資料啦，緩存與資料與資料庫資料不一緻。
緩存維護方案二
雙寫操作，先操作緩存，在操作資料庫。
1）線程A發起一個寫操作，第一步set cache
3）線程B發起一個寫操作，set cache，
4）線程B第二步寫入新資料到DB
這樣看，也沒啥問題。，但是有時候可能事與願違，我們再看第二個流程圖，如下:
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
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資料才删除緩存