本篇文章給大家?guī)砹岁P(guān)于Redis如何解決緩存不一致的問題，緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致是如何發(fā)生的，下面就一起來看一下吧，希望對大家有幫助。

推薦學(xué)習(xí)：Redis學(xué)習(xí)教程

緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致是如何發(fā)生的？

首先，我們得清楚“數(shù)據(jù)的一致性”具體是啥意思。其實(shí)，這里的“一致性”包含了兩種情況：

• 緩存中有數(shù)據(jù)，那么，緩存的數(shù)據(jù)值需要和數(shù)據(jù)庫中的值相同；
• 緩存中本身沒有數(shù)據(jù)，那么，數(shù)據(jù)庫中的值必須是最新值。

不符合這兩種情況的，就屬于緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致問題了。不過，當(dāng)緩存的讀寫模式不同時，緩存數(shù)據(jù)不一致的發(fā)生情況不一樣，我們的應(yīng)對方法也會有所不同，所以，我們先按照緩存讀寫模式，來分別了解下不同模式下的緩存不一致情況。我們可以把緩存分成讀寫緩存和只讀緩存。

對于讀寫緩存來說，如果要對數(shù)據(jù)進(jìn)行增刪改，就需要在緩存中進(jìn)行，同時還要根據(jù)采取的寫回策略，決定是否同步寫回到數(shù)據(jù)庫中。

同步直寫策略：寫緩存時，也同步寫數(shù)據(jù)庫，緩存和數(shù)據(jù)庫中的數(shù)據(jù)一致；

異步寫回策略：寫緩存時不同步寫數(shù)據(jù)庫，等到數(shù)據(jù)從緩存中淘汰時，再寫回?cái)?shù)據(jù)庫。使用這種策略時，如果數(shù)據(jù)還沒有寫回?cái)?shù)據(jù)庫，緩存就發(fā)生了故障，那么，此時，數(shù)據(jù)庫就沒有最新的數(shù)據(jù)了。

所以，對于讀寫緩存來說，要想保證緩存和數(shù)據(jù)庫中的數(shù)據(jù)一致，就要采用同步直寫策略。不過，需要注意的是，如果采用這種策略，就需要同時更新緩存和數(shù)據(jù)庫。所以，我們要在業(yè)務(wù)應(yīng)用中使用事務(wù)機(jī)制，來保證緩存和數(shù)據(jù)庫的更新具有原子性，也就是說，兩者要不一起更新，要不都不更新，返回錯誤信息，進(jìn)行重試。否則，我們就無法實(shí)現(xiàn)同步直寫。

當(dāng)然，在有些場景下，我們對數(shù)據(jù)一致性的要求可能不是那么高，比如說緩存的是電商商品的非關(guān)鍵屬性或者短視頻的創(chuàng)建或修改時間等，那么，我們可以使用異步寫回策略。

下面我們再來說說只讀緩存。對于只讀緩存來說，如果有數(shù)據(jù)新增，會直接寫入數(shù)據(jù)庫；而有數(shù)據(jù)刪改時，就需要把只讀緩存中的數(shù)據(jù)標(biāo)記為無效。這樣一來，應(yīng)用后續(xù)再訪問這些增刪改的數(shù)據(jù)時，因?yàn)榫彺嬷袥]有相應(yīng)的數(shù)據(jù)，就會發(fā)生緩存缺失。此時，應(yīng)用再從數(shù)據(jù)庫中把數(shù)據(jù)讀入緩存，這樣后續(xù)再訪問數(shù)據(jù)時，就能夠直接從緩存中讀取了。

接下來，以 Tomcat 向 MySQL 中寫入和刪改數(shù)據(jù)為例，來給你解釋一下，數(shù)據(jù)的增刪改操作具體是如何進(jìn)行的，如下圖所示：

從圖中可以看到，Tomcat 上運(yùn)行的應(yīng)用，無論是新增（Insert 操作）、修改（Update 操作）、還是刪除（Delete 操作）數(shù)據(jù) X，都會直接在數(shù)據(jù)庫中增改刪。當(dāng)然，如果應(yīng)用執(zhí)行的是修改或刪除操作，還會刪除緩存的數(shù)據(jù) X。

那么，這個過程中會不會出現(xiàn)數(shù)據(jù)不一致的情況呢？考慮到新增數(shù)據(jù)和刪改數(shù)據(jù)的情況不一樣，所以我們分開來看。

1. 新增數(shù)據(jù)
   如果是新增數(shù)據(jù)，數(shù)據(jù)會直接寫到數(shù)據(jù)庫中，不用對緩存做任何操作，此時，緩存中本身就沒有新增數(shù)據(jù)，而數(shù)據(jù)庫中是最新值，這種情況符合我們剛剛所說的一致性的第 2 種情況，所以，此時，緩存和數(shù)據(jù)庫的數(shù)據(jù)是一致的。
2. 刪改數(shù)據(jù)
   如果發(fā)生刪改操作，應(yīng)用既要更新數(shù)據(jù)庫，也要在緩存中刪除數(shù)據(jù)。這兩個操作如果無法保證原子性，也就是說，要不都完成，要不都沒完成，此時，就會出現(xiàn)數(shù)據(jù)不一致問題了。這個問題比較復(fù)雜，我們來分析一下。

我們假設(shè)應(yīng)用先刪除緩存，再更新數(shù)據(jù)庫，如果緩存刪除成功，但是數(shù)據(jù)庫更新失敗，那么，應(yīng)用再訪問數(shù)據(jù)時，緩存中沒有數(shù)據(jù)，就會發(fā)生緩存缺失。然后，應(yīng)用再訪問數(shù)據(jù)庫，但是數(shù)據(jù)庫中的值為舊值，應(yīng)用就訪問到舊值了。
我來舉個例子說明一下，可以先看看下面的圖片

應(yīng)用要把數(shù)據(jù) X 的值從 10 更新為 3，先在 Redis 緩存中刪除了 X 的緩存值，但是更新數(shù)據(jù)庫卻失敗了。如果此時有其他并發(fā)的請求訪問 X，會發(fā)現(xiàn) Redis 中緩存缺失，緊接著，請求就會訪問數(shù)據(jù)庫，讀到的卻是舊值 10。
你可能會問，如果我們先更新數(shù)據(jù)庫，再刪除緩存中的值，是不是就可以解決這個問題呢？我們再來分析下。
如果應(yīng)用先完成了數(shù)據(jù)庫的更新，但是，在刪除緩存時失敗了，那么，數(shù)據(jù)庫中的值是新值，而緩存中的是舊值，這肯定是不一致的。這個時候，如果有其他的并發(fā)請求來訪問數(shù)據(jù)，按照正常的緩存訪問流程，就會先在緩存中查詢，但此時，就會讀到舊值了。
我還是借助一個例子來說明一下。

應(yīng)用要把數(shù)據(jù) X 的值從 10 更新為 3，先成功更新了數(shù)據(jù)庫，然后在 Redis 緩存中刪除 X 的緩存，但是這個操作卻失敗了，這個時候，數(shù)據(jù)庫中 X 的新值為 3，Redis 中的 X 的緩存值為 10，這肯定是不一致的。如果剛好此時有其他客戶端也發(fā)送請求訪問 X，會先在 Redis 中查詢，該客戶端會發(fā)現(xiàn)緩存命中，但是讀到的卻是舊值 10。

好了，到這里，我們可以看到，在更新數(shù)據(jù)庫和刪除緩存值的過程中，無論這兩個操作的執(zhí)行順序誰先誰后，只要有一個操作失敗了，就會導(dǎo)致客戶端讀取到舊值。我畫了下面這張表，總結(jié)了剛剛所說的這兩種情況。

問題發(fā)生的原因我們知道了，那該怎么解決呢？

如何解決數(shù)據(jù)不一致問題？

首先，我給你介紹一種方法：重試機(jī)制。

具體來說，可以把要刪除的緩存值或者是要更新的數(shù)據(jù)庫值暫存到消息隊(duì)列中（例如使用 Kafka 消息隊(duì)列）。當(dāng)應(yīng)用沒有能夠成功地刪除緩存值或者是更新數(shù)據(jù)庫值時，可以從消息隊(duì)列中重新讀取這些值，然后再次進(jìn)行刪除或更新。

如果能夠成功地刪除或更新，我們就要把這些值從消息隊(duì)列中去除，以免重復(fù)操作，此時，我們也可以保證數(shù)據(jù)庫和緩存的數(shù)據(jù)一致了。否則的話，我們還需要再次進(jìn)行重試。如果重試超過的一定次數(shù)，還是沒有成功，我們就需要向業(yè)務(wù)層發(fā)送報(bào)錯信息了。

下圖顯示了先更新數(shù)據(jù)庫，再刪除緩存值時，如果緩存刪除失敗，再次重試后刪除成功的情況，你可以看下。

剛剛說的是在更新數(shù)據(jù)庫和刪除緩存值的過程中，其中一個操作失敗的情況，實(shí)際上，即使這兩個操作第一次執(zhí)行時都沒有失敗，當(dāng)有大量并發(fā)請求時，應(yīng)用還是有可能讀到不一致的數(shù)據(jù)。

同樣，我們按照不同的刪除和更新順序，分成兩種情況來看。在這兩種情況下，我們的解決方法也有所不同。

情況一：先刪除緩存，再更新數(shù)據(jù)庫。

假設(shè)線程 A 刪除緩存值后，還沒有來得及更新數(shù)據(jù)庫（比如說有網(wǎng)絡(luò)延遲），線程 B 就開始讀取數(shù)據(jù)了，那么這個時候，線程 B 會發(fā)現(xiàn)緩存缺失，就只能去數(shù)據(jù)庫讀取。這會帶來兩個問題：

1. 線程 B 讀取到了舊值；
2. 線程 B 是在緩存缺失的情況下讀取的數(shù)據(jù)庫，所以，它還會把舊值寫入緩存，這可能會導(dǎo)致其他線程從緩存中讀到舊值。

等到線程 B 從數(shù)據(jù)庫讀取完數(shù)據(jù)、更新了緩存后，線程 A 才開始更新數(shù)據(jù)庫，此時，緩存中的數(shù)據(jù)是舊值，而數(shù)據(jù)庫中的是最新值，兩者就不一致了。

我用一張表來匯總下這種情況。

這該怎么辦呢？我來給你提供一種解決方案。

在線程 A 更新完數(shù)據(jù)庫值以后，我們可以讓它先 sleep 一小段時間，再進(jìn)行一次緩存刪除操作。

之所以要加上 sleep 的這段時間，就是為了讓線程 B 能夠先從數(shù)據(jù)庫讀取數(shù)據(jù)，再把缺失的數(shù)據(jù)寫入緩存，然后，線程 A 再進(jìn)行刪除。所以，線程 A sleep 的時間，就需要大于線程 B 讀取數(shù)據(jù)再寫入緩存的時間。這個時間怎么確定呢？建議你在業(yè)務(wù)程序運(yùn)行的時候，統(tǒng)計(jì)下線程讀數(shù)據(jù)和寫緩存的操作時間，以此為基礎(chǔ)來進(jìn)行估算。

這樣一來，其它線程讀取數(shù)據(jù)時，會發(fā)現(xiàn)緩存缺失，所以會從數(shù)據(jù)庫中讀取最新值。因?yàn)檫@個方案會在第一次刪除緩存值后，延遲一段時間再次進(jìn)行刪除，所以我們也把它叫做“延遲雙刪”。

下面的這段偽代碼就是“延遲雙刪”方案的示例，你可以看下。

redis.delKey(X) db.update(X) Thread.sleep(N) redis.delKey(X)

情況二：先更新數(shù)據(jù)庫值，再刪除緩存值。

如果線程 A 刪除了數(shù)據(jù)庫中的值，但還沒來得及刪除緩存值，線程 B 就開始讀取數(shù)據(jù)了，那么此時，線程 B 查詢緩存時，發(fā)現(xiàn)緩存命中，就會直接從緩存中讀取舊值。不過，在這種情況下，如果其他線程并發(fā)讀緩存的請求不多，那么，就不會有很多請求讀取到舊值。而且，線程 A 一般也會很快刪除緩存值，這樣一來，其他線程再次讀取時，就會發(fā)生緩存缺失，進(jìn)而從數(shù)據(jù)庫中讀取最新值。所以，這種情況對業(yè)務(wù)的影響較小。

我再畫一張表，帶你總結(jié)下先更新數(shù)據(jù)庫、再刪除緩存值的情況。

好了，到這里，我們了解到了，緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致一般是由兩個原因?qū)е碌模医o你提供了相應(yīng)的解決方案。

• 刪除緩存值或更新數(shù)據(jù)庫失敗而導(dǎo)致數(shù)據(jù)不一致，你可以使用重試機(jī)制確保刪除或更新操作成功。
• 在刪除緩存值、更新數(shù)據(jù)庫的這兩步操作中，有其他線程的并發(fā)讀操作，導(dǎo)致其他線程讀取到舊值，應(yīng)對方案是延遲雙刪。

推薦學(xué)習(xí)：Redis視頻教程