項(xiàng)目中有遇到這個(gè)問(wèn)題，跟MySQL中的數(shù)據(jù)不一致，研究一番發(fā)現(xiàn)這里面細(xì)節(jié)并不簡(jiǎn)單，特此記錄一下。

寫(xiě)在前面

嚴(yán)格意義上任何非原子操作都不可能保證一致性，除非用阻塞讀寫(xiě)實(shí)現(xiàn)強(qiáng)一致性，所以緩存架構(gòu)我們追求的目標(biāo)是最終一致性。
緩存就是通過(guò)犧牲強(qiáng)一致性來(lái)提高性能的。

這是由CAP理論決定的。緩存系統(tǒng)適用的場(chǎng)景就是非強(qiáng)一致性的場(chǎng)景，它屬于CAP中的AP。

以下3 種緩存讀寫(xiě)策略各有優(yōu)劣，不存在最佳。

三種讀寫(xiě)緩存策略

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

Cache-Aside Pattern，即旁路緩存模式，它的提出是為了盡可能地解決緩存與數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致問(wèn)題。

讀 ：從緩存讀取數(shù)據(jù)，讀到直接返回。如果讀取不到的話，從數(shù)據(jù)庫(kù)加載，寫(xiě)入緩存后，再返回響應(yīng)。
寫(xiě)：更新的時(shí)候，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。

Read-Through/Write-Through（讀寫(xiě)穿透）

Read/Write Through Pattern 中服務(wù)端把 cache 視為主要數(shù)據(jù)存儲(chǔ)，從中讀取數(shù)據(jù)并將數(shù)據(jù)寫(xiě)入其中。cache 服務(wù)負(fù)責(zé)將此數(shù)據(jù)讀取和寫(xiě)入 DB，從而減輕了應(yīng)用程序的職責(zé)。

因?yàn)槲覀兘?jīng)常使用的分布式緩存 Redis 并沒(méi)有提供 cache 將數(shù)據(jù)寫(xiě)入DB的功能，所以使用并不多。

寫(xiě)：先查 cache，cache 中不存在，直接更新 DB。cache 中存在，則先更新 cache，然后 cache 服務(wù)自己更新 DB（同步更新 cache和DB）。

讀：從 cache 中讀取數(shù)據(jù)，讀取到就直接返回 。讀取不到的話，先從 DB 加載，寫(xiě)入到 cache 后返回響應(yīng)。

Write Behind Pattern（異步緩存寫(xiě)入）

Write Behind Pattern 和 Read/Write Through Pattern 很相似，兩者都是由 cache 服務(wù)來(lái)負(fù)責(zé) cache 和 DB 的讀寫(xiě)。

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

很明顯，這種方式對(duì)數(shù)據(jù)一致性帶來(lái)了更大的挑戰(zhàn)，比如cache數(shù)據(jù)可能還沒(méi)異步更新DB的話，cache服務(wù)可能就掛掉了，反而會(huì)帶來(lái)更大的災(zāi)難。

這種策略在我們平時(shí)開(kāi)發(fā)過(guò)程中也非常非常少見(jiàn)，但是不代表它的應(yīng)用場(chǎng)景少，比如消息隊(duì)列中消息的異步寫(xiě)入磁盤(pán)、MySQL 的 InnoDB Buffer Pool 機(jī)制都用到了這種策略。

Write Behind Pattern 下 DB 的寫(xiě)性能非常高，非常適合一些數(shù)據(jù)經(jīng)常變化又對(duì)數(shù)據(jù)一致性要求沒(méi)那么高的場(chǎng)景，比如瀏覽量、點(diǎn)贊量。

旁路緩存模式解析

Cache Aside Pattern 的一些疑問(wèn)

旁路緩存模式是我們平時(shí)中使用最多的。下面根據(jù)上面介紹的旁路緩存模式，我們可以有以下幾個(gè)疑問(wèn)。

為什么寫(xiě)操作是刪除緩存，而不是更新緩存

答：線程A先發(fā)起一個(gè)寫(xiě)操作，第一步先更新數(shù)據(jù)庫(kù)。線程B再發(fā)起一個(gè)寫(xiě)操作，第二步更新了數(shù)據(jù)庫(kù)，由于網(wǎng)絡(luò)等原因，線程B先更新了緩存，線程A更新緩存。

這時(shí)候，緩存保存的是A的數(shù)據(jù)（老數(shù)據(jù)），數(shù)據(jù)庫(kù)保存的是B的數(shù)據(jù)（新數(shù)據(jù)），數(shù)據(jù)不一致了，臟數(shù)據(jù)出現(xiàn)啦。如果是刪除緩存取代更新緩存則不會(huì)出現(xiàn)這個(gè)臟數(shù)據(jù)問(wèn)題。

實(shí)際上要寫(xiě)操作的時(shí)候更新緩存也是可以的，不過(guò)我們需要加一個(gè)鎖/分布式鎖來(lái)保證更新cache的時(shí)候不存在線程安全問(wèn)題。

在寫(xiě)數(shù)據(jù)的過(guò)程中，為什么要先更新DB在刪除緩存

答：比如說(shuō)請(qǐng)求1 是寫(xiě)操作，要是先刪除緩存A，請(qǐng)求2是讀操作，先讀緩存A，發(fā)現(xiàn)緩存被刪除了(被請(qǐng)求1刪除了)，然后去讀數(shù)據(jù)庫(kù)，但是此時(shí)請(qǐng)求1還沒(méi)來(lái)得及把數(shù)據(jù)及時(shí)更新，那么請(qǐng)求2讀的就是舊數(shù)據(jù)，并且請(qǐng)求2還會(huì)把讀到的舊數(shù)據(jù)放到緩存中，造成了數(shù)據(jù)的不一致。

其實(shí)要先刪緩存，再更新數(shù)據(jù)庫(kù)也是可以，如采用延時(shí)雙刪策略
休眠1秒，再次淘汰緩存 這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。不一定是1秒，看你業(yè)務(wù)決定的，不過(guò)不推薦這種做法，因?yàn)樵谶@1秒內(nèi)可能發(fā)生因素很多，它的不確定性太大。

在寫(xiě)數(shù)據(jù)的過(guò)程中，先更新DB，后刪除cache就沒(méi)有問(wèn)題了么？

答： 理論上來(lái)說(shuō)還是可能會(huì)出現(xiàn)數(shù)據(jù)不一致性的問(wèn)題，不過(guò)概率非常小。

假設(shè)這會(huì)有兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A做查詢操作，一個(gè)請(qǐng)求B做更新操作，那么會(huì)有如下情形產(chǎn)生

（1）緩存剛好失效
（2）請(qǐng)求A查詢數(shù)據(jù)庫(kù)，得一個(gè)舊值
（3）請(qǐng)求B將新值寫(xiě)入數(shù)據(jù)庫(kù)
（4）請(qǐng)求B刪除緩存
（5）請(qǐng)求A將查到的舊值寫(xiě)入緩存 ok，如果發(fā)生上述情況，確實(shí)是會(huì)發(fā)生臟數(shù)據(jù)。

然而，發(fā)生這種情況的概率并不高

發(fā)生上述情況有一個(gè)先天性條件，就是步驟（3）的寫(xiě)數(shù)據(jù)庫(kù)操作比步驟（2）的讀數(shù)據(jù)庫(kù)操作耗時(shí)更短，才有可能使得步驟（4）先于步驟（5）。

可是，仔細(xì)想想，數(shù)據(jù)庫(kù)的讀操作的速度遠(yuǎn)快于寫(xiě)操作的（不然做讀寫(xiě)分離干嘛，做讀寫(xiě)分離的意義就是因?yàn)樽x操作比較快，耗資源少），因此步驟（3）耗時(shí)比步驟（2）更短，這一情形很難出現(xiàn)。

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

答： 如果刪除緩存過(guò)程中失敗了就會(huì)造成不一致問(wèn)題

如何解決？
使用Canal去訂閱數(shù)據(jù)庫(kù)的binlog，獲得需要操作的數(shù)據(jù)。另起一個(gè)程序，獲得這個(gè)訂閱程序傳來(lái)的信息，進(jìn)行刪除緩存操作。

Cache Aside Pattern 的缺陷

缺陷1：首次請(qǐng)求數(shù)據(jù)一定不在 cache 的問(wèn)題

解決辦法：可以將熱點(diǎn)數(shù)據(jù)提前放入cache 中。

缺陷2：寫(xiě)操作比較頻繁的話導(dǎo)致cache中的數(shù)據(jù)會(huì)被頻繁被刪除，這樣會(huì)影響緩存命中率 。

數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)強(qiáng)一致場(chǎng)景 ：更新DB的時(shí)候同樣更新cache，不過(guò)我們需要加一個(gè)鎖/分布式鎖來(lái)保證更新cache的時(shí)候不存在線程安全問(wèn)題?？梢远虝旱卦试S數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)不一致的場(chǎng)景 ：更新DB的時(shí)候同樣更新cache，但是給緩存加一個(gè)比較短的過(guò)期時(shí)間，這樣的話就可以保證即使數(shù)據(jù)不一致的話影響也比較小。

到此這篇關(guān)于淺談Redis跟MySQL的雙寫(xiě)問(wèn)題解決方案的文章就介紹到這了,更多相關(guān)Redis MySQL雙寫(xiě)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論