淺談Redis跟MySQL的雙寫問題解決方案

Posted on by

項目中有遇到這個問題，跟MySQL中的數據不一致，研究一番發現這裡面細節並不簡單，特此記錄一下。

寫在前面

嚴格意義上任何非原子操作都不可能保證一致性，除非用阻塞讀寫實現強一致性，所以緩存架構我們追求的目標是最終一致性。
緩存就是通過犧牲強一致性來提高性能的。

這是由CAP理論決定的。緩存系統適用的場景就是非強一致性的場景，它屬於CAP中的AP。

以下3 種緩存讀寫策略各有優劣，不存在最佳。

三種讀寫緩存策略

Cache-Aside Pattern（旁路緩存模式）

Cache-Aside Pattern，即旁路緩存模式，它的提出是為瞭盡可能地解決緩存與數據庫的數據不一致問題。

在這裡插入圖片描述

讀 ：從緩存讀取數據，讀到直接返回。如果讀取不到的話，從數據庫加載，寫入緩存後，再返回響應。
寫：更新的時候，先更新數據庫，然後再刪除緩存。

在這裡插入圖片描述

Read-Through/Write-Through（讀寫穿透）

Read/Write Through Pattern 中服務端把 cache 視為主要數據存儲，從中讀取數據並將數據寫入其中。cache 服務負責將此數據讀取和寫入 DB，從而減輕瞭應用程序的職責。

因為我們經常使用的分佈式緩存 Redis 並沒有提供 cache 將數據寫入DB的功能，所以使用並不多。

寫：先查 cache，cache 中不存在，直接更新 DB。cache 中存在，則先更新 cache，然後 cache 服務自己更新 DB（同步更新 cache和DB）。

讀：從 cache 中讀取數據，讀取到就直接返回 。讀取不到的話，先從 DB 加載，寫入到 cache 後返回響應。

Write Behind Pattern（異步緩存寫入）

Write Behind Pattern 和 Read/Write Through Pattern 很相似，兩者都是由 cache 服務來負責 cache 和 DB 的讀寫。

但是，兩個又有很大的不同：Read/Write Through 是同步更新 cache 和 DB，而 Write Behind Caching 則是隻更新緩存，不直接更新 DB，而是改為異步批量的方式來更新 DB。

很明顯，這種方式對數據一致性帶來瞭更大的挑戰，比如cache數據可能還沒異步更新DB的話，cache服務可能就掛掉瞭，反而會帶來更大的災難。

這種策略在我們平時開發過程中也非常非常少見，但是不代表它的應用場景少，比如消息隊列中消息的異步寫入磁盤、MySQL 的 InnoDB Buffer Pool 機制都用到瞭這種策略。

Write Behind Pattern 下 DB 的寫性能非常高，非常適合一些數據經常變化又對數據一致性要求沒那麼高的場景，比如瀏覽量、點贊量。

旁路緩存模式解析

Cache Aside Pattern 的一些疑問

旁路緩存模式是我們平時中使用最多的。下面根據上面介紹的旁路緩存模式，我們可以有以下幾個疑問。

為什麼寫操作是刪除緩存，而不是更新緩存

答：線程A先發起一個寫操作，第一步先更新數據庫。線程B再發起一個寫操作，第二步更新瞭數據庫，由於網絡等原因，線程B先更新瞭緩存，線程A更新緩存。

這時候，緩存保存的是A的數據（老數據），數據庫保存的是B的數據（新數據），數據不一致瞭，臟數據出現啦。如果是刪除緩存取代更新緩存則不會出現這個臟數據問題。

實際上要寫操作的時候更新緩存也是可以的，不過我們需要加一個鎖/分佈式鎖來保證更新cache的時候不存在線程安全問題。

在寫數據的過程中，為什麼要先更新DB在刪除緩存

答：比如說請求1 是寫操作，要是先刪除緩存A，請求2是讀操作，先讀緩存A，發現緩存被刪除瞭(被請求1刪除瞭)，然後去讀數據庫，但是此時請求1還沒來得及把數據及時更新，那麼請求2讀的就是舊數據，並且請求2還會把讀到的舊數據放到緩存中，造成瞭數據的不一致。

其實要先刪緩存，再更新數據庫也是可以，如采用延時雙刪策略
休眠1秒，再次淘汰緩存 這麼做，可以將1秒內所造成的緩存臟數據，再次刪除。不一定是1秒，看你業務決定的，不過不推薦這種做法，因為在這1秒內可能發生因素很多，它的不確定性太大。

在寫數據的過程中，先更新DB，後刪除cache就沒有問題瞭麼？

答： 理論上來說還是可能會出現數據不一致性的問題，不過概率非常小。

假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那麼會有如下情形產生

（1）緩存剛好失效
（2）請求A查詢數據庫，得一個舊值
（3）請求B將新值寫入數據庫
（4）請求B刪除緩存
（5）請求A將查到的舊值寫入緩存 ok，如果發生上述情況，確實是會發生臟數據。

然而，發生這種情況的概率並不高

發生上述情況有一個先天性條件，就是步驟（3）的寫數據庫操作比步驟（2）的讀數據庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。

可是，仔細想想，數據庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。

還有其他造成不一致的原因麼？

答： 如果刪除緩存過程中失敗瞭就會造成不一致問題

如何解決？
使用Canal去訂閱數據庫的binlog，獲得需要操作的數據。另起一個程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。

Cache Aside Pattern 的缺陷

缺陷1：首次請求數據一定不在 cache 的問題

解決辦法：可以將熱點數據提前放入cache 中。

缺陷2：寫操作比較頻繁的話導致cache中的數據會被頻繁被刪除，這樣會影響緩存命中率 。

數據庫和緩存數據強一致場景 ：更新DB的時候同樣更新cache，不過我們需要加一個鎖/分佈式鎖來保證更新cache的時候不存在線程安全問題。可以短暫地允許數據庫和緩存數據不一致的場景 ：更新DB的時候同樣更新cache，但是給緩存加一個比較短的過期時間，這樣的話就可以保證即使數據不一致的話影響也比較小。

到此這篇關於淺談Redis跟MySQL的雙寫問題解決方案的文章就介紹到這瞭,更多相關Redis MySQL雙寫內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：