點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)"書"，獲取

來(lái)源：后端技術(shù)漫談

當(dāng)我們?cè)谧鰯?shù)據(jù)庫(kù)與緩存數(shù)據(jù)同步時(shí)，究竟更新緩存，還是刪除緩存，究竟是先操作數(shù)據(jù)庫(kù)，還是先操作緩存？本文帶大家深度分析數(shù)據(jù)庫(kù)與緩存的雙寫問(wèn)題，以供大家參考。

本篇文章主要內(nèi)容

• 數(shù)據(jù)緩存

• • 為何要使用緩存

  • 哪類數(shù)據(jù)適合緩存

  • 緩存的利與弊

• 如何保證緩存和數(shù)據(jù)庫(kù)一致性

• • 不更新緩存，而是刪除緩存

  • 先操作緩存，還是先操作數(shù)據(jù)庫(kù)

  • 非要保證數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)強(qiáng)一致該怎么辦

• 緩存和數(shù)據(jù)庫(kù)一致性實(shí)戰(zhàn)

• • 實(shí)戰(zhàn)：先刪除緩存，再更新數(shù)據(jù)庫(kù)

  • 實(shí)戰(zhàn)：先更新數(shù)據(jù)庫(kù)，再刪緩存

  • 實(shí)戰(zhàn)：緩存延時(shí)雙刪

  • 實(shí)戰(zhàn)：刪除緩存重試機(jī)制

  • 實(shí)戰(zhàn)：讀取binlog異步刪除緩存

數(shù)據(jù)緩存

在我們實(shí)際的業(yè)務(wù)場(chǎng)景中，一定有很多需要做數(shù)據(jù)緩存的場(chǎng)景，比如售賣商品的頁(yè)面，包括了許多并發(fā)訪問(wèn)量很大的數(shù)據(jù)，它們可以稱作是是“熱點(diǎn)”數(shù)據(jù)，這些數(shù)據(jù)有一個(gè)特點(diǎn)，就是更新頻率低，讀取頻率高，這些數(shù)據(jù)應(yīng)該盡量被緩存，從而減少請(qǐng)求打到數(shù)據(jù)庫(kù)上的機(jī)會(huì)，減輕數(shù)據(jù)庫(kù)的壓力。

為何要使用緩存

緩存是為了追求“快”而存在的。我們用代碼舉一個(gè)例子。

我在自己的Demo代碼倉(cāng)庫(kù)中增加了兩個(gè)查詢庫(kù)存的接口getStockByDB和getStockByCache，分別表示從數(shù)據(jù)庫(kù)和緩存查詢某商品的庫(kù)存量。

隨后我們用JMeter進(jìn)行并發(fā)請(qǐng)求測(cè)試。（JMeter的使用請(qǐng)參考我之前寫的文章：點(diǎn)擊這里）

需要聲明的是，我的測(cè)試并不嚴(yán)謹(jǐn)，只是作對(duì)比測(cè)試，不要作為實(shí)際服務(wù)性能的參考。

這是兩個(gè)接口的代碼：

/***?查詢庫(kù)存：通過(guò)數(shù)據(jù)庫(kù)查詢庫(kù)存*?@param?sid*?@return*/ @RequestMapping("/getStockByDB/{sid}") @ResponseBody public?String?getStockByDB(@PathVariable?int?sid)?{int?count;try?{count?=?stockService.getStockCountByDB(sid);}?catch?(Exception?e)?{LOGGER.error("查詢庫(kù)存失敗：[{}]",?e.getMessage());return?"查詢庫(kù)存失敗";}LOGGER.info("商品Id:?[{}]?剩余庫(kù)存為:?[{}]",?sid,?count);return?String.format("商品Id:?%d 剩余庫(kù)存為：%d",?sid,?count); }/***?查詢庫(kù)存：通過(guò)緩存查詢庫(kù)存*?緩存命中：返回庫(kù)存*?緩存未命中：查詢數(shù)據(jù)庫(kù)寫入緩存并返回*?@param?sid*?@return*/ @RequestMapping("/getStockByCache/{sid}") @ResponseBody public?String?getStockByCache(@PathVariable?int?sid)?{Integer?count;try?{count?=?stockService.getStockCountByCache(sid);if?(count?==?null)?{count?=?stockService.getStockCountByDB(sid);LOGGER.info("緩存未命中，查詢數(shù)據(jù)庫(kù)，并寫入緩存");stockService.setStockCountToCache(sid,?count);}}?catch?(Exception?e)?{LOGGER.error("查詢庫(kù)存失敗：[{}]",?e.getMessage());return?"查詢庫(kù)存失敗";}LOGGER.info("商品Id:?[{}]?剩余庫(kù)存為:?[{}]",?sid,?count);return?String.format("商品Id:?%d 剩余庫(kù)存為：%d",?sid,?count); }

首先設(shè)置為10000個(gè)并發(fā)請(qǐng)求的情況下，運(yùn)行JMeter，結(jié)果首先出現(xiàn)了大量的報(bào)錯(cuò)，10000個(gè)請(qǐng)求中98%的請(qǐng)求都直接失敗了。讓人很慌張~

打開日志，報(bào)錯(cuò)如下：

SpringBoot內(nèi)置的Tomcat最大并發(fā)數(shù)搞的鬼，其默認(rèn)值為200，對(duì)于10000的并發(fā)，單機(jī)服務(wù)實(shí)在是力不從心。當(dāng)然，你可以修改這里的并發(fā)數(shù)設(shè)置，但是你的小機(jī)器仍然可能會(huì)扛不住。

將其修改為如下配置后，我的小機(jī)器才在通過(guò)緩存拿庫(kù)存的情況下，保證了10000個(gè)并發(fā)的100%返回請(qǐng)求：

server.tomcat.max-threads=10000 server.tomcat.max-connections=10000

可以看到，不使用緩存的情況下，吞吐量為668個(gè)請(qǐng)求每秒：

使用緩存的情況下，吞吐量為2177個(gè)請(qǐng)求每秒：

在這種“十分不嚴(yán)謹(jǐn)”的對(duì)比下，有緩存對(duì)于一臺(tái)單機(jī)，性能提升了3倍多，如果在多臺(tái)機(jī)器，更多并發(fā)的情況下，由于數(shù)據(jù)庫(kù)有了更大的壓力，緩存的性能優(yōu)勢(shì)應(yīng)該會(huì)更加明顯。

測(cè)完了這個(gè)小實(shí)驗(yàn)，我看了眼我掛著 MySQL 的小水管騰訊云服務(wù)器，生怕他被這么高流量搞掛。這種突發(fā)的流量，指不定會(huì)被檢測(cè)為異常攻擊流量呢~

我用的是騰訊云服務(wù)器1C4G2M，活動(dòng)買的，很便宜。這里打個(gè)免費(fèi)的廣告，請(qǐng)騰訊云看到后聯(lián)系我給我打錢 ;)

哪類數(shù)據(jù)適合緩存

緩存量大但又不常變化的數(shù)據(jù)，比如詳情，評(píng)論等。對(duì)于那些經(jīng)常變化的數(shù)據(jù)，其實(shí)并不適合緩存，一方面會(huì)增加系統(tǒng)的復(fù)雜性（緩存的更新，緩存臟數(shù)據(jù)），另一方面也給系統(tǒng)帶來(lái)一定的不穩(wěn)定性（緩存系統(tǒng)的維護(hù)）。

但一些極端情況下，你需要將一些會(huì)變動(dòng)的數(shù)據(jù)進(jìn)行緩存，比如想要頁(yè)面顯示準(zhǔn)實(shí)時(shí)的庫(kù)存數(shù)，或者其他一些特殊業(yè)務(wù)場(chǎng)景。這時(shí)候你需要保證緩存不能（一直）有臟數(shù)據(jù)，這就需要再深入討論一下。

緩存的利與弊

我們到底該不該上緩存的，這其實(shí)也是個(gè)trade-off（權(quán)衡）的問(wèn)題。

上緩存的優(yōu)點(diǎn)：

• 能夠縮短服務(wù)的響應(yīng)時(shí)間，給用戶帶來(lái)更好的體驗(yàn)。

• 能夠增大系統(tǒng)的吞吐量，依然能夠提升用戶體驗(yàn)。

• 減輕數(shù)據(jù)庫(kù)的壓力，防止高峰期數(shù)據(jù)庫(kù)被壓垮，導(dǎo)致整個(gè)線上服務(wù)BOOM！

上了緩存，也會(huì)引入很多額外的問(wèn)題：

• 緩存有多種選型，是內(nèi)存緩存，memcached還是redis，你是否都熟悉，如果不熟悉，無(wú)疑增加了維護(hù)的難度（本來(lái)是個(gè)純潔的數(shù)據(jù)庫(kù)系統(tǒng)）。

• 緩存系統(tǒng)也要考慮分布式，比如redis的分布式緩存還會(huì)有很多坑，無(wú)疑增加了系統(tǒng)的復(fù)雜性。

• 在特殊場(chǎng)景下，如果對(duì)緩存的準(zhǔn)確性有非常高的要求，就必須考慮緩存和數(shù)據(jù)庫(kù)的一致性問(wèn)題。

本文想要重點(diǎn)討論的，就是緩存和數(shù)據(jù)庫(kù)的一致性問(wèn)題，各位看官且往下看。

如何保證緩存和數(shù)據(jù)庫(kù)一致性

說(shuō)了這么多緩存的必要性，那么使用緩存是不是就是一個(gè)很簡(jiǎn)單的事情了呢，我之前也一直是這么覺得的，直到遇到了需要緩存與數(shù)據(jù)庫(kù)保持強(qiáng)一致的場(chǎng)景，才知道讓數(shù)據(jù)庫(kù)數(shù)據(jù)和緩存數(shù)據(jù)保持一致性是一門很高深的學(xué)問(wèn)。

從遠(yuǎn)古的硬件緩存，操作系統(tǒng)緩存開始，緩存就是一門獨(dú)特的學(xué)問(wèn)。這個(gè)問(wèn)題也被業(yè)界探討了非常久，爭(zhēng)論至今。我翻閱了很多資料，發(fā)現(xiàn)其實(shí)這是一個(gè)權(quán)衡的問(wèn)題。值得好好講講。

以下的討論會(huì)引入幾方觀點(diǎn)，我會(huì)跟著觀點(diǎn)來(lái)寫代碼驗(yàn)證所提到的問(wèn)題。

不更新緩存，而是刪除緩存

大部分觀點(diǎn)認(rèn)為，做緩存不應(yīng)該是去更新緩存，而是應(yīng)該刪除緩存，然后由下個(gè)請(qǐng)求去去緩存，發(fā)現(xiàn)不存在后再讀取數(shù)據(jù)庫(kù)，寫入緩存。

觀點(diǎn)引用：《分布式之?dāng)?shù)據(jù)庫(kù)和緩存雙寫一致性方案解析》孤獨(dú)煙

原因一：線程安全角度

同時(shí)有請(qǐng)求A和請(qǐng)求B進(jìn)行更新操作，那么會(huì)出現(xiàn)

（1）線程A更新了數(shù)據(jù)庫(kù)

（2）線程B更新了數(shù)據(jù)庫(kù)

（3）線程B更新了緩存

（4）線程A更新了緩存

這就出現(xiàn)請(qǐng)求A更新緩存應(yīng)該比請(qǐng)求B更新緩存早才對(duì)，但是因?yàn)榫W(wǎng)絡(luò)等原因，B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮。

原因二：業(yè)務(wù)場(chǎng)景角度

有如下兩點(diǎn)：

（1）如果你是一個(gè)寫數(shù)據(jù)庫(kù)場(chǎng)景比較多，而讀數(shù)據(jù)場(chǎng)景比較少的業(yè)務(wù)需求，采用這種方案就會(huì)導(dǎo)致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁的更新，浪費(fèi)性能。

（2）如果你寫入數(shù)據(jù)庫(kù)的值，并不是直接寫入緩存的，而是要經(jīng)過(guò)一系列復(fù)雜的計(jì)算再寫入緩存。那么，每次寫入數(shù)據(jù)庫(kù)后，都再次計(jì)算寫入緩存的值，無(wú)疑是浪費(fèi)性能的。顯然，刪除緩存更為適合。

其實(shí)如果業(yè)務(wù)非常簡(jiǎn)單，只是去數(shù)據(jù)庫(kù)拿一個(gè)值，寫入緩存，那么更新緩存也是可以的。但是，淘汰緩存操作簡(jiǎn)單，并且?guī)?lái)的副作用只是增加了一次cache miss，建議作為通用的處理方式。

先操作緩存，還是先操作數(shù)據(jù)庫(kù)

那么問(wèn)題就來(lái)了，我們是先刪除緩存，然后再更新數(shù)據(jù)庫(kù)，還是先更新數(shù)據(jù)庫(kù)，再刪緩存呢？

先來(lái)看看大佬們?cè)趺凑f(shuō)。

《【58沈劍架構(gòu)系列】緩存架構(gòu)設(shè)計(jì)細(xì)節(jié)二三事》58沈劍：

對(duì)于一個(gè)不能保證事務(wù)性的操作，一定涉及“哪個(gè)任務(wù)先做，哪個(gè)任務(wù)后做”的問(wèn)題，解決這個(gè)問(wèn)題的方向是：如果出現(xiàn)不一致，誰(shuí)先做對(duì)業(yè)務(wù)的影響較小，就誰(shuí)先執(zhí)行。

假設(shè)先淘汰緩存，再寫數(shù)據(jù)庫(kù)：第一步淘汰緩存成功，第二步寫數(shù)據(jù)庫(kù)失敗，則只會(huì)引發(fā)一次Cache miss。

假設(shè)先寫數(shù)據(jù)庫(kù)，再淘汰緩存：第一步寫數(shù)據(jù)庫(kù)操作成功，第二步淘汰緩存失敗，則會(huì)出現(xiàn)DB中是新數(shù)據(jù)，Cache中是舊數(shù)據(jù)，數(shù)據(jù)不一致。

沈劍老師說(shuō)的沒有問(wèn)題，不過(guò)沒完全考慮好并發(fā)請(qǐng)求時(shí)的數(shù)據(jù)臟讀問(wèn)題，讓我們?cè)賮?lái)看看孤獨(dú)煙老師《分布式之?dāng)?shù)據(jù)庫(kù)和緩存雙寫一致性方案解析》：

先刪緩存，再更新數(shù)據(jù)庫(kù)

該方案會(huì)導(dǎo)致請(qǐng)求數(shù)據(jù)不一致

同時(shí)有一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢操作。那么會(huì)出現(xiàn)如下情形:

（1）請(qǐng)求A進(jìn)行寫操作，刪除緩存

（2）請(qǐng)求B查詢發(fā)現(xiàn)緩存不存在

（3）請(qǐng)求B去數(shù)據(jù)庫(kù)查詢得到舊值

（4）請(qǐng)求B將舊值寫入緩存

（5）請(qǐng)求A將新值寫入數(shù)據(jù)庫(kù)

上述情況就會(huì)導(dǎo)致不一致的情形出現(xiàn)。而且，如果不采用給緩存設(shè)置過(guò)期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。

所以先刪緩存，再更新數(shù)據(jù)庫(kù)并不是一勞永逸的解決方案，再看看先更新數(shù)據(jù)庫(kù)，再刪緩存這種方案怎么樣？

先更新數(shù)據(jù)庫(kù)，再刪緩存這種情況不存在并發(fā)問(wèn)題么？

不是的。假設(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將新值寫入數(shù)據(jù)庫(kù)

（4）請(qǐng)求B刪除緩存

（5）請(qǐng)求A將查到的舊值寫入緩存

ok，如果發(fā)生上述情況，確實(shí)是會(huì)發(fā)生臟數(shù)據(jù)。

然而，發(fā)生這種情況的概率又有多少呢？

發(fā)生上述情況有一個(gè)先天性條件，就是步驟（3）的寫數(shù)據(jù)庫(kù)操作比步驟（2）的讀數(shù)據(jù)庫(kù)操作耗時(shí)更短，才有可能使得步驟（4）先于步驟（5）。可是，大家想想，數(shù)據(jù)庫(kù)的讀操作的速度遠(yuǎn)快于寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因?yàn)樽x操作比較快，耗資源少），因此步驟（3）耗時(shí)比步驟（2）更短，這一情形很難出現(xiàn)。

先更新數(shù)據(jù)庫(kù)，再刪緩存依然會(huì)有問(wèn)題，不過(guò)，問(wèn)題出現(xiàn)的可能性會(huì)因?yàn)樯厦嬲f(shuō)的原因，變得比較低！

(補(bǔ)充說(shuō)明：我用了“先更新數(shù)據(jù)庫(kù)，再刪緩存”且不設(shè)過(guò)期時(shí)間策略，會(huì)不會(huì)有問(wèn)題呢？由于先緩存和更新數(shù)據(jù)庫(kù)不是原子的，如果更新了數(shù)據(jù)庫(kù)，程序歇逼，就沒刪緩存，由于沒有過(guò)期策略，就永遠(yuǎn)臟數(shù)據(jù)了。)

所以，如果你想實(shí)現(xiàn)基礎(chǔ)的緩存數(shù)據(jù)庫(kù)雙寫一致的邏輯，那么在大多數(shù)情況下，在不想做過(guò)多設(shè)計(jì)，增加太大工作量的情況下，請(qǐng)先更新數(shù)據(jù)庫(kù)，再刪緩存!

我非要數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)強(qiáng)一致怎么辦

那么，如果我非要保證絕對(duì)一致性怎么辦，先給出結(jié)論：

沒有辦法做到絕對(duì)的一致性，這是由CAP理論決定的，緩存系統(tǒng)適用的場(chǎng)景就是非強(qiáng)一致性的場(chǎng)景，所以它屬于CAP中的AP。

所以，我們得委曲求全，可以去做到BASE理論中說(shuō)的最終一致性。

最終一致性強(qiáng)調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過(guò)一段時(shí)間的同步后，最終能夠達(dá)到一個(gè)一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達(dá)到一致，而不需要實(shí)時(shí)保證系統(tǒng)數(shù)據(jù)的強(qiáng)一致性

大佬們給出了到達(dá)最終一致性的解決思路，主要是針對(duì)上面兩種雙寫策略（先刪緩存，再更新數(shù)據(jù)庫(kù)/先更新數(shù)據(jù)庫(kù)，再刪緩存）導(dǎo)致的臟數(shù)據(jù)問(wèn)題，進(jìn)行相應(yīng)的處理，來(lái)保證最終一致性。

緩存延時(shí)雙刪

問(wèn)：先刪除緩存，再更新數(shù)據(jù)庫(kù)中避免臟數(shù)據(jù)？

答案：采用延時(shí)雙刪策略。

上文我們提到，在先刪除緩存，再更新數(shù)據(jù)庫(kù)的情況下，如果不采用給緩存設(shè)置過(guò)期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。

那么延時(shí)雙刪怎么解決這個(gè)問(wèn)題呢？

（1）先淘汰緩存

（2）再寫數(shù)據(jù)庫(kù)（這兩步和原來(lái)一樣）

（3）休眠1秒，再次淘汰緩存

這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。

那么，這個(gè)1秒怎么確定的，具體該休眠多久呢？

針對(duì)上面的情形，讀者應(yīng)該自行評(píng)估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。然后寫數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請(qǐng)求結(jié)束，寫請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

如果你用了mysql的讀寫分離架構(gòu)怎么辦？

ok，在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢操作。

（1）請(qǐng)求A進(jìn)行寫操作，刪除緩存

（2）請(qǐng)求A將數(shù)據(jù)寫入數(shù)據(jù)庫(kù)了，

（3）請(qǐng)求B查詢緩存發(fā)現(xiàn)，緩存沒有值

（4）請(qǐng)求B去從庫(kù)查詢，這時(shí)，還沒有完成主從同步，因此查詢到的是舊值

（5）請(qǐng)求B將舊值寫入緩存

（6）數(shù)據(jù)庫(kù)完成主從同步，從庫(kù)變?yōu)樾轮?/p>

上述情形，就是數(shù)據(jù)不一致的原因。還是使用雙刪延時(shí)策略。只是，睡眠時(shí)間修改為在主從同步的延時(shí)時(shí)間基礎(chǔ)上，加幾百ms。

采用這種同步淘汰策略，吞吐量降低怎么辦？

ok，那就將第二次刪除作為異步的。自己起一個(gè)線程，異步刪除。這樣，寫的請(qǐng)求就不用沉睡一段時(shí)間后了，再返回。這么做，加大吞吐量。

所以在先刪除緩存，再更新數(shù)據(jù)庫(kù)的情況下，可以使用延時(shí)雙刪的策略，來(lái)保證臟數(shù)據(jù)只會(huì)存活一段時(shí)間，就會(huì)被準(zhǔn)確的數(shù)據(jù)覆蓋。

在先更新數(shù)據(jù)庫(kù)，再刪緩存的情況下，緩存出現(xiàn)臟數(shù)據(jù)的情況雖然可能性極小，但也會(huì)出現(xiàn)。我們依然可以用延時(shí)雙刪策略，在請(qǐng)求A對(duì)緩存寫入了臟的舊值之后，再次刪除緩存。來(lái)保證去掉臟緩存。

刪緩存失敗了怎么辦：重試機(jī)制

看似問(wèn)題都已經(jīng)解決了，但其實(shí)，還有一個(gè)問(wèn)題沒有考慮到，那就是刪除緩存的操作，失敗了怎么辦？比如延時(shí)雙刪的時(shí)候，第二次緩存刪除失敗了，那不還是沒有清除臟數(shù)據(jù)嗎？

解決方案就是再加上一個(gè)重試機(jī)制，保證刪除緩存成功。

參考孤獨(dú)煙老師給的方案圖：

方案一：

流程如下所示

（1）更新數(shù)據(jù)庫(kù)數(shù)據(jù)；

（2）緩存因?yàn)榉N種問(wèn)題刪除失敗

（3）將需要?jiǎng)h除的key發(fā)送至消息隊(duì)列

（4）自己消費(fèi)消息，獲得需要?jiǎng)h除的key

（5）繼續(xù)重試刪除操作，直到成功

然而，該方案有一個(gè)缺點(diǎn)，對(duì)業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動(dòng)一個(gè)訂閱程序去訂閱數(shù)據(jù)庫(kù)的binlog，獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中，另起一段程序，獲得這個(gè)訂閱程序傳來(lái)的信息，進(jìn)行刪除緩存操作。

方案二：

流程如下圖所示：

（1）更新數(shù)據(jù)庫(kù)數(shù)據(jù)

（2）數(shù)據(jù)庫(kù)會(huì)將操作信息寫入binlog日志當(dāng)中

（3）訂閱程序提取出所需要的數(shù)據(jù)以及key

（4）另起一段非業(yè)務(wù)代碼，獲得該信息

（5）嘗試刪除緩存操作，發(fā)現(xiàn)刪除失敗

（6）將這些信息發(fā)送至消息隊(duì)列

（7）重新從消息隊(duì)列中獲得該數(shù)據(jù)，重試操作。

擴(kuò)展閱讀

更新緩存的的Design Pattern有四種：

• Cache aside

• Read through

• Write through

• Write behind caching，這里有陳皓的總結(jié)文章可以進(jìn)行學(xué)習(xí)。

https://coolshell.cn/articles/17416.html

小結(jié)

引用陳浩《緩存更新的套路》最后的總結(jié)語(yǔ)作為小結(jié)：

分布式系統(tǒng)里要么通過(guò)2PC或是Paxos協(xié)議保證一致性，要么就是拼命的降低并發(fā)時(shí)臟數(shù)據(jù)的概率

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

異構(gòu)數(shù)據(jù)庫(kù)本來(lái)就沒辦法強(qiáng)一致，只是盡可能減少時(shí)間窗口，達(dá)到最終一致性。

還有別忘了設(shè)置過(guò)期時(shí)間，這是個(gè)兜底方案

結(jié)束語(yǔ)

本文總結(jié)并探討了緩存數(shù)據(jù)庫(kù)雙寫一致性問(wèn)題。

文章內(nèi)容大致可以總結(jié)為如下幾點(diǎn)：

• 對(duì)于讀多寫少的數(shù)據(jù)，請(qǐng)使用緩存。

• 為了保持?jǐn)?shù)據(jù)庫(kù)和緩存的一致性，會(huì)導(dǎo)致系統(tǒng)吞吐量的下降。

• 為了保持?jǐn)?shù)據(jù)庫(kù)和緩存的一致性，會(huì)導(dǎo)致業(yè)務(wù)代碼邏輯復(fù)雜。

• 緩存做不到絕對(duì)一致性，但可以做到最終一致性。

• 對(duì)于需要保證緩存數(shù)據(jù)庫(kù)數(shù)據(jù)一致的情況，請(qǐng)盡量考慮對(duì)一致性到底有多高要求，選定合適的方案，避免過(guò)度設(shè)計(jì)。

參考

• https://cloud.tencent.com/developer/article/1574827

• https://www.jianshu.com/p/2936a5c65e6b

• https://www.cnblogs.com/rjzheng/p/9041659.html

• https://www.cnblogs.com/codeon/p/8287563.html

• https://www.jianshu.com/p/0275ecca2438

• https://www.jianshu.com/p/dc1e5091a0d8

• https://coolshell.cn/articles/17416.html

想知道更多？掃描下面的二維碼關(guān)注我

后臺(tái)回復(fù)"技術(shù)"，加入技術(shù)群

【精彩推薦】

• 原創(chuàng)|OpenAPI標(biāo)準(zhǔn)規(guī)范

• 如此簡(jiǎn)單| ES最全詳細(xì)使用教程

• ClickHouse到底是什么？為什么如此牛逼！

• 原來(lái)ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數(shù)據(jù)？

• 微服務(wù)下如何解耦？對(duì)于已經(jīng)緊耦合下如何重構(gòu)？

• 如何構(gòu)建一套高性能、高可用、低成本的視頻處理系統(tǒng)？

• 架構(gòu)之道：分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)

• 星巴克不使用兩階段提交
  

點(diǎn)個(gè)贊+在看，少個(gè) bug?????

總結(jié)

以上是生活随笔為你收集整理的好文推荐 | 缓存与数据库一致性问题深度剖析 （修订）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。