并發(fā)環(huán)境下，先操作數(shù)據(jù)庫還是先操作緩存？

前言

在分布式系統(tǒng)中，緩存和數(shù)據(jù)庫同時存在時，如果有寫操作，先操作數(shù)據(jù)庫還是先操作緩存呢？本文將分5種方案展開闡述對比，謝謝閱讀~

緩存維護方案一

如果是一讀（線程B）一寫（線程A）操作，「先操作緩存，再操作數(shù)據(jù)庫」。流程圖如下所示：

• 1.線程A發(fā)起一個寫操作，第一步del cache
  

• 2.線程A第二步寫入新數(shù)據(jù)到DB
• 3.線程B發(fā)起一個讀操作，cache miss緩存失效了。
• 4.線程B從DB獲取最新數(shù)據(jù)
• 5.線程B執(zhí)行set cache，把從DB讀到的數(shù)據(jù)，更新到緩存。

「這樣看，沒啥問題」。我們再看第二個流程圖，如下：

• 1.線程A發(fā)起一個寫操作，第一步del cache
• 2.此時線程B發(fā)起一個讀操作，cache miss
• 3.線程B繼續(xù)讀DB，讀出來一個老數(shù)據(jù)
• 4.然后老數(shù)據(jù)設置入cache
• 5.線程A寫入DB最新的數(shù)據(jù)

OK，醬紫，就有問題了吧，老數(shù)據(jù)入到緩存了，「每次讀都是老數(shù)據(jù)啦，緩存與數(shù)據(jù)與數(shù)據(jù)庫數(shù)據(jù)不一致了」。

?

緩存維護方案二

上個方案是一讀一寫，如果是雙寫操作，「先操作緩存，在操作數(shù)據(jù)庫」，會怎么樣呢？

• 1.線程A發(fā)起一個寫操作，第一步set cache
• 2.線程A第二步寫入新數(shù)據(jù)到DB
• 3.線程B發(fā)起一個寫操作，set cache
• 4.線程B第二步寫入新數(shù)據(jù)到DB

「這樣看，也沒啥問題。」，但是有時候可能事與愿違，我們再看第二個流程圖，如下:

• 1.線程A發(fā)起一個寫操作，第一步set cache
• 2.線程B發(fā)起一個寫操作，第一步set cache
• 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

有些朋友可能認為，在第2步刪除緩存之前，線程B讀過來呢？這時候，讀到的是緩存老數(shù)據(jù)，這個可以認為是正常業(yè)務邏輯呀，下次再讀取就是正確數(shù)據(jù)了。

這種方案「沒有明顯的并發(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ù)」，如何解決呢？解決方案如下流程圖：

緩存維護總結

綜上所述，在分布式系統(tǒng)中，緩存和數(shù)據(jù)庫同時存在時，如果有寫操作的時候，「先操作數(shù)據(jù)庫，再操作緩存」。如下：

• 1.讀取緩存中是否有相關數(shù)據(jù)
• 2.如果緩存中有相關數(shù)據(jù)value，則返回
• 3.如果緩存中沒有相關數(shù)據(jù)，則從數(shù)據(jù)庫讀取相關數(shù)據(jù)放入緩存中key->value，再返回
• 4.如果有更新寫數(shù)據(jù)，則先操作數(shù)據(jù)庫，再操作緩存
• 5.為了保證第四步更新緩存成功，使用binlog異步通知操作
• 6.如果是主從數(shù)據(jù)庫，binglog取自于從庫
• 7.如果是一主多從，每個從庫都要采集binlog，然后消費端收到最后一臺binlog數(shù)據(jù)才刪除緩存

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??