背景

在高并發(fā)的業(yè)務(wù)場(chǎng)景下，系統(tǒng)的性能瓶頸往往是出現(xiàn)在數(shù)據(jù)庫(kù)上，用戶并發(fā)訪問(wèn)過(guò)大，壓力都打到數(shù)據(jù)庫(kù)上。所以一般都會(huì)用redis做緩存層，起到一個(gè)緩沖作用，讓請(qǐng)求先訪問(wèn)到緩存層，而不是直接去訪問(wèn)數(shù)據(jù)庫(kù)，減輕數(shù)據(jù)庫(kù)壓力，從而減少網(wǎng)絡(luò)請(qǐng)求的延遲響應(yīng)，提高系統(tǒng)性能。一般在使用緩存和數(shù)據(jù)庫(kù)結(jié)合的時(shí)候就會(huì)面臨數(shù)據(jù)一致性問(wèn)題，可能會(huì)經(jīng)常遇到“明明數(shù)據(jù)已經(jīng)更新了，怎么還是顯示舊的”，下面就來(lái)分析下產(chǎn)生的原因及其對(duì)應(yīng)處理方案。

數(shù)據(jù)更新的常見(jiàn)操作

注意：我們講的數(shù)據(jù)一致性的前提是數(shù)據(jù)庫(kù)更新和緩存刪除不把它當(dāng)成一個(gè)原子性操作。因?yàn)楦卟l(fā)場(chǎng)景下，我們不可能引入分布式鎖將這兩者操作綁定為一個(gè)原子性操作，如果綁定的話就會(huì)很大程度上影響系統(tǒng)并發(fā)性能，所以一般只追求最終一致性，本文也是針對(duì)非追求強(qiáng)一致性要求的場(chǎng)景，金融或銀行業(yè)務(wù)的小伙伴請(qǐng)自行判斷。

本文涉及到一種常用的緩存模式：Cache-Aside Pattern，即旁路緩存模式，這種模式就是為了盡可能地解決緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性問(wèn)題。這種模式分為讀請(qǐng)求和寫(xiě)請(qǐng)求兩種。
讀請(qǐng)求流程：
讀的時(shí)候，先讀取緩存，若緩存命中的話，直接返回?cái)?shù)據(jù)。
若緩存沒(méi)有命中，就去讀數(shù)據(jù)庫(kù)，從數(shù)據(jù)庫(kù)取出數(shù)據(jù)，放入緩存后，返回響應(yīng)。

寫(xiě)請(qǐng)求流程：
更新數(shù)據(jù)的時(shí)候，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。

下面羅列出常見(jiàn)的幾種數(shù)據(jù)更新的方式及其對(duì)應(yīng)的問(wèn)題：

1、先更新數(shù)據(jù)庫(kù)，后更新緩存

流程如下圖：

1.請(qǐng)求A先發(fā)起一個(gè)寫(xiě)操作，先更新數(shù)據(jù)庫(kù)
2.請(qǐng)求B再發(fā)起一個(gè)寫(xiě)操作，更新了數(shù)據(jù)庫(kù)
3.由于網(wǎng)絡(luò)等原因，請(qǐng)求B先更新了緩存
4.請(qǐng)求A更新緩存

問(wèn)題如上所示，緩存保存的是A的數(shù)據(jù)（舊數(shù)據(jù)），數(shù)據(jù)庫(kù)保存的是B的數(shù)據(jù)（新數(shù)據(jù)），數(shù)據(jù)不一致，臟數(shù)據(jù)出現(xiàn)。

這種場(chǎng)景一般不推薦使用。因?yàn)橛械臉I(yè)務(wù)需求中緩存里的值并不是直接從數(shù)據(jù)庫(kù)中查出的，有的是需要經(jīng)過(guò)一系列操作計(jì)算出緩存的值，那么這時(shí)候你要更新緩存的代價(jià)是很高的。如果這時(shí)有大量請(qǐng)求需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行寫(xiě)操作，但是讀的請(qǐng)求并不多，那么每次寫(xiě)操作都更新一次緩存，性能損耗是非常大的。

舉個(gè)最簡(jiǎn)單的例子：數(shù)據(jù)庫(kù)中有一個(gè)num字段的值為1，這時(shí)有10個(gè)請(qǐng)求對(duì)其進(jìn)行遞增加一的操作，但是這期間讀請(qǐng)求很少，如果是先更新數(shù)據(jù)庫(kù)，后更新緩存的話，那么就會(huì)有十個(gè)請(qǐng)求對(duì)緩存進(jìn)行更新，這樣會(huì)有大量的冷數(shù)據(jù)產(chǎn)生。如果選擇刪除緩存而不是更新緩存，那么在讀請(qǐng)求進(jìn)來(lái)的時(shí)候就只會(huì)更新一次緩存。這樣的話哪種操作消耗的資源更多是不是就很明顯了。

2、先更新緩存，后更新數(shù)據(jù)庫(kù)

這一種情況和上一種是類(lèi)似的，這里就不再贅述。

3、先刪除緩存，后更新數(shù)據(jù)庫(kù)

流程如下圖：

1.請(qǐng)求A先發(fā)起一個(gè)寫(xiě)操作，先刪除緩存，此時(shí)會(huì)還沒(méi)更新數(shù)據(jù)庫(kù)完成（可能在還沒(méi)更新，或者正在更新，但事務(wù)還未提交）
2.此時(shí)請(qǐng)求B發(fā)起一個(gè)讀操作，讀取到緩存數(shù)據(jù)為空
3.請(qǐng)求B在緩存中讀不到數(shù)據(jù)，就去讀取數(shù)據(jù)庫(kù)并將舊數(shù)據(jù)寫(xiě)入緩存（臟數(shù)據(jù)）
4.請(qǐng)求A更新DB完成

問(wèn)題如上所示，緩存保存的是舊數(shù)據(jù)（請(qǐng)求B將臟數(shù)據(jù)寫(xiě)入了緩存），如果是一個(gè)讀多寫(xiě)少的數(shù)據(jù)，可能臟數(shù)據(jù)會(huì)存在比較長(zhǎng)的時(shí)間（要么后續(xù)有更新，要么等待緩存過(guò)期），這在業(yè)務(wù)上是不能接受的。

4、先更新數(shù)據(jù)庫(kù)，后刪除緩存

流程如下圖：

1.請(qǐng)求A先發(fā)起一個(gè)寫(xiě)操作，先更新數(shù)據(jù)庫(kù)，此時(shí)還沒(méi)刪除緩存完成
2.此時(shí)請(qǐng)求B發(fā)起一個(gè)讀操作，讀取到的緩存數(shù)據(jù)為舊數(shù)據(jù)
3.請(qǐng)求A刪除緩存

問(wèn)題如上所示，在請(qǐng)求A更新數(shù)據(jù)庫(kù)和刪除緩存之間請(qǐng)求B會(huì)讀取到舊數(shù)據(jù)，因?yàn)榇藭r(shí)整個(gè)請(qǐng)求A的操作還沒(méi)有完成，并且讀到舊數(shù)據(jù)的時(shí)間是非常短的，而后請(qǐng)求后會(huì)刪除緩存，所以可以滿足數(shù)據(jù)最終一致性要求。但是不排除請(qǐng)求A刪除緩存失敗的可能。

分析

先來(lái)對(duì)以上幾種方式進(jìn)行概括分析，可以分為這兩種選擇，1、是更新緩存還是刪除緩存，2、是先更新數(shù)據(jù)庫(kù)還是先操作緩存

是更新緩存還是刪除緩存，結(jié)合上面的第1、2點(diǎn)的例子可以得出是選擇刪除緩存

更新緩存相對(duì)于刪除緩存兩點(diǎn)劣勢(shì)：

• 如果你寫(xiě)入的緩存，是經(jīng)過(guò)復(fù)雜計(jì)算才得到的話。更新緩存的頻率高，性能損耗大。
• 在寫(xiě)操作多，讀數(shù)據(jù)少的場(chǎng)景下，緩存數(shù)據(jù)很多時(shí)候還沒(méi)被讀取到，又被更新了，浪費(fèi)了資源（寫(xiě)多讀少的場(chǎng)景用緩存不是很劃算）

根據(jù)上面分析的結(jié)論是刪除緩存，那么是先更新數(shù)據(jù)庫(kù)還是先刪除緩存？
由上面第3點(diǎn)的例子，可以看出如果是先刪除緩存再更新DB，會(huì)有較大可能導(dǎo)致緩存保存的是舊數(shù)據(jù)，數(shù)據(jù)庫(kù)保存的是新數(shù)據(jù)。

有的人會(huì)說(shuō)，那第4點(diǎn)的先更新數(shù)據(jù)庫(kù)再刪除緩存，不也可能導(dǎo)致緩存中是舊數(shù)據(jù)？

其實(shí)只要是非原子性操作就都可能出現(xiàn)數(shù)據(jù)不一致的情況，但是第四點(diǎn)這種方式，一般是因?yàn)閯h除緩存失敗等原因，才會(huì)導(dǎo)致緩存了臟數(shù)據(jù)，這個(gè)概率會(huì)低很多。

解決方案

其實(shí)上面第3點(diǎn)和第4點(diǎn)的問(wèn)題，刪除緩存失敗的情況，我們只要保證他刪除成功就可以。

一、延時(shí)雙刪緩存

以上面第3點(diǎn)例，先刪除緩存再更新數(shù)據(jù)庫(kù)，最直觀能想到的最簡(jiǎn)單的辦法就是延時(shí)雙刪。什么是延時(shí)雙刪，看完如下圖流程就明白了。

在原來(lái)第3點(diǎn)，先刪除緩存再更新數(shù)據(jù)庫(kù)的基礎(chǔ)上，在請(qǐng)求A更新完數(shù)據(jù)庫(kù)后，休眠一下（比如1秒），然后再次刪除緩存。

這種方案只有休眠那一下，可能有臟數(shù)據(jù)被讀取，一般業(yè)務(wù)也可以接受的。這個(gè)休眠延遲時(shí)間一般要根據(jù)讀業(yè)務(wù)邏輯的耗時(shí)去估算（比較難）然后增加相應(yīng)幾百毫秒的延遲。

但是如果第二次刪除緩存又失敗了？給key設(shè)置一個(gè)過(guò)期時(shí)間？業(yè)務(wù)上能否接受在key過(guò)期之前的這段時(shí)間內(nèi)的數(shù)據(jù)不一致？

二、重試刪除緩存

根據(jù)業(yè)務(wù)預(yù)估緩存過(guò)期時(shí)間很麻煩，而且你預(yù)估的也不一定準(zhǔn)，可能還有其他什么原因造成過(guò)期時(shí)間過(guò)短或過(guò)長(zhǎng)而影響了正常業(yè)務(wù)。
既然如此，前兩次都刪除失敗了，那我多刪他幾次保證他刪除成功就可以了。

利用消息隊(duì)列進(jìn)行重試刪除緩存的補(bǔ)償機(jī)制，流程如下圖：

1.寫(xiě)請(qǐng)求進(jìn)來(lái)，先更新數(shù)據(jù)庫(kù)
2.由于某些原因，刪除緩存失敗
3.把刪除失敗的key推送到消息隊(duì)列
4.消費(fèi)隊(duì)列消息，獲取要?jiǎng)h除的key
5.重試刪除緩存

上面第3點(diǎn)和第四點(diǎn)的例子，均可以使用此方案。但這個(gè)方案有一個(gè)缺點(diǎn)：會(huì)對(duì)業(yè)務(wù)代碼造成大量侵入，耦合在一起。

三、異步淘汰緩存

重試刪除緩存機(jī)制已經(jīng)滿足保持?jǐn)?shù)據(jù)一致性的要求，但是會(huì)造成好多業(yè)務(wù)代碼入侵。所以可以優(yōu)化下：開(kāi)一個(gè)訂閱服務(wù)（獨(dú)立的中間系統(tǒng)），負(fù)責(zé)通過(guò)訂閱數(shù)據(jù)庫(kù)（如mysql）的binlog來(lái)異步淘汰緩存。

mysql更新數(shù)據(jù)后在binlog日志中都有相應(yīng)的記錄，我們可以訂閱mysql的binlog對(duì)緩存進(jìn)行操作。流程如下圖：

異步淘汰機(jī)制可以達(dá)到想要的雙寫(xiě)一致性效果，但是對(duì)應(yīng)的也有他的缺點(diǎn)：增加了整個(gè)系統(tǒng)的復(fù)雜度。

踩坑

注意??：上面講的數(shù)據(jù)庫(kù)和緩存都是普通的單機(jī)情況下的。

這里講下我以前踩過(guò)的坑，上面第3點(diǎn)的例子，先刪除緩存，后更新數(shù)據(jù)庫(kù)，然后異步淘汰。

這里還隱藏著一個(gè)問(wèn)題：如果你使用的是mysql讀寫(xiě)分離架構(gòu)的話，主從同步之間會(huì)有時(shí)延問(wèn)題，這就有可能產(chǎn)生臟數(shù)據(jù)。

看如下圖流程你就明白了，先不復(fù)雜化，搞個(gè)大家都能看懂的。我假設(shè)緩存刪除成功，更新數(shù)據(jù)庫(kù)也成功，這兩者之間沒(méi)有其他讀請(qǐng)求插入：

如上所示，請(qǐng)求A和請(qǐng)求B操作時(shí)序沒(méi)問(wèn)題，是主從同步的時(shí)延問(wèn)題(假設(shè)1s)，導(dǎo)致讀請(qǐng)求讀取到從庫(kù)中的臟數(shù)據(jù)

1.請(qǐng)求A先發(fā)起一個(gè)寫(xiě)請(qǐng)求，先刪除了緩存
2.請(qǐng)求A請(qǐng)求主庫(kù)進(jìn)行更新數(shù)據(jù)
3.主庫(kù)與從庫(kù)進(jìn)行數(shù)據(jù)同步
4.請(qǐng)求B發(fā)起一個(gè)讀請(qǐng)求，讀取緩存中的數(shù)據(jù)為空
5.請(qǐng)求B去DB從庫(kù)中取數(shù)據(jù)，由于主庫(kù)壓力大/處理數(shù)據(jù)量多/網(wǎng)絡(luò)原因等，此時(shí)主從同步還沒(méi)完成。請(qǐng)求B讀取到DB從庫(kù)中的舊數(shù)據(jù)并寫(xiě)入緩存中
6.最后主從同步完成

我之前的解決方案：如果緩存數(shù)據(jù)為空，需要查詢DB再設(shè)置到緩存的操作，就強(qiáng)制將查詢的DB指向master進(jìn)行查詢。

總結(jié)

每種方式和方案都各有利弊。

比如先刪除緩存，后更新數(shù)據(jù)庫(kù)這個(gè)方式，我們最終選擇了重試刪除緩存+更新Redis的時(shí)候強(qiáng)制走主庫(kù)查詢就能解決問(wèn)題，但是這操作會(huì)對(duì)業(yè)務(wù)代碼進(jìn)行大量的侵入，但是不需要增加新的中間系統(tǒng)去處理，不需要增加整體的服務(wù)的復(fù)雜度。

如果我們選擇異步淘汰緩存的方案，利用訂閱binlog日志進(jìn)行搭建獨(dú)立的中間系統(tǒng)來(lái)操作緩存，但就樣就增加了系統(tǒng)復(fù)雜度，復(fù)雜度增加帶來(lái)的風(fēng)險(xiǎn)往往是后知后覺(jué)的。

其實(shí)每種方案的選擇都需要我們對(duì)本身的業(yè)務(wù)進(jìn)行評(píng)估，沒(méi)有一種技術(shù)是對(duì)所有業(yè)務(wù)都通用的。我覺(jué)得最難的是尋找最佳效益的平衡點(diǎn)的取舍問(wèn)題，就像常說(shuō)的：沒(méi)有最好的，只有最適合你的。

我是六濤sheliutao，文章編寫(xiě)總結(jié)不易，轉(zhuǎn)載注明出處，喜歡本篇文章的小伙伴歡迎點(diǎn)贊、關(guān)注，有問(wèn)題可以評(píng)論區(qū)留言或者私信我，相互交流！！！