前言
在分布式系統(tǒng)中，緩存和數(shù)據(jù)庫同時存在時贫悄，如果有寫操作的時候瑞驱，先操作數(shù)據(jù)庫還是先操作緩存呢？
先思考一下窄坦，可能會存在哪些問題唤反，再往下看晰筛。下面我分幾種方案闡述。
緩存維護方案一
假設(shè)有一寫（線程A）一讀（線程B）操作拴袭，先操作緩存读第，在操作數(shù)據(jù)庫，如下流程圖所示
1）線程A發(fā)起一個寫操作拥刻，第一步del cache
2）線程A第二步寫入新數(shù)據(jù)到DB
3）線程B發(fā)起一個讀操作怜瞒，cache miss，
4）線程B從DB獲取最新數(shù)據(jù)
5）請求B同時set cache
這樣看般哼，沒啥問題吴汪。我們再看第二個流程圖，如下：
1）線程A發(fā)起一個寫操作蒸眠，第一步del cache
2）此時線程B發(fā)起一個讀操作漾橙，cache miss
3）線程B繼續(xù)讀DB，讀出來一個老數(shù)據(jù)
4）然后老數(shù)據(jù)入cache
5）線程A寫入了最新的數(shù)據(jù)
OK楞卡，醬紫霜运，就有問題了吧，老數(shù)據(jù)入到緩存了蒋腮，每次讀都是老數(shù)據(jù)啦淘捡，緩存與數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)不一致。
緩存維護方案二
雙寫操作池摧，先操作緩存焦除，在操作數(shù)據(jù)庫。
1）線程A發(fā)起一個寫操作作彤，第一步set cache
2）線程B發(fā)起一個寫操作膘魄，第一步setcache
3）線程B寫入數(shù)據(jù)庫到DB
4）線程A寫入數(shù)據(jù)庫到DB
執(zhí)行完后，緩存保存的是B操作后的數(shù)據(jù)竭讳，數(shù)據(jù)庫是A操作后的數(shù)據(jù)创葡，緩存和數(shù)據(jù)庫數(shù)據(jù)不一致。
緩存維護方案三
一寫（線程A）一讀（線程B）操作代咸，先操作數(shù)據(jù)庫蹈丸，再操作緩存。
1）線程A發(fā)起一個寫操作呐芥，第一步write DB
2）線程A第二步del cache
3）線程B發(fā)起一個讀操作逻杖，cache miss
4）線程B從DB獲取最新數(shù)據(jù)
5）線程B同時set cache
這種方案沒有明顯的并發(fā)問題，但是有可能步驟二刪除緩存失敗思瘟，雖然概率比較小荸百，優(yōu)于方案一和方案二，平時工作中也是使用方案三滨攻。
綜上對比够话，我們一般采用方案三蓝翰，但是有沒有完美全解決方案三的弊端的方法呢？
緩存維護方案四
這個是方案三的改進方案女嘲，都是先操作數(shù)據(jù)庫再操作緩存畜份，我們來看一下流程圖：
通過數(shù)據(jù)庫的binlog來異步淘汰key，以mysql為例欣尼，可以使用阿里的canal將binlog日志采集發(fā)送到MQ隊列里面爆雹，然后通過ACK機制確認處理 這條更新消息，刪除緩存愕鼓，保證數(shù)據(jù)緩存一致性钙态。
但是呢還有個問題，如果是主從數(shù)據(jù)庫呢菇晃？
緩存維護方案五
主從DB問題：因為主從DB同步存在同時延時時間如果刪除緩存之后册倒，數(shù)據(jù)同步到備庫之前已經(jīng)有請求過來時，會從備庫中讀到臟數(shù)據(jù)磺送，如何解決呢驻子？
解決方案如下流程圖：
緩存維護總結(jié)
綜上所述，在分布式系統(tǒng)中册着，緩存和數(shù)據(jù)庫同時存在時拴孤，如果有寫操作的時候，先操作數(shù)據(jù)庫甲捏，再操作緩存。如下：
（1）讀取緩存中是否有相關(guān)數(shù)據(jù)
（2）如果緩存中有相關(guān)數(shù)據(jù)value鞭执，則返回
（3）如果緩存中沒有相關(guān)數(shù)據(jù)司顿，則從數(shù)據(jù)庫讀取相關(guān)數(shù)據(jù)放入緩存中key->value，再返回
（4）如果有更新數(shù)據(jù)兄纺，則先更新數(shù)據(jù)大溜，再刪除緩存
（5）為了保證第四步刪除緩存成功，使用binlog異步刪除
（6）如果是主從數(shù)據(jù)庫估脆，binglog取自于從庫
（7）如果是一主多從钦奋，每個從庫都要采集binlog，然后消費端收到最后一臺binlog數(shù)據(jù)才刪除緩存
-----------------------------------------------------作者--------------------------------------------
VX公眾號搜索：撿田螺的小男孩
