本篇文章給大家帶來了關于Redis如何解決緩存不一致的問題，緩存和數據庫的數據不一致是如何發生的，下面就一起來看一下吧，希望對大家有幫助。

推薦學習：Redis學習教程

緩存和數據庫的數據不一致是如何發生的？

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

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

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

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

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

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

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

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

下面我們再來說說只讀緩存。對于只讀緩存來說，如果有數據新增，會直接寫入數據庫；而有數據刪改時，就需要把只讀緩存中的數據標記為無效。這樣一來，應用后續再訪問這些增刪改的數據時，因為緩存中沒有相應的數據，就會發生緩存缺失。此時，應用再從數據庫中把數據讀入緩存，這樣后續再訪問數據時，就能夠直接從緩存中讀取了。

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

從圖中可以看到，Tomcat 上運行的應用，無論是新增（Insert 操作）、修改（Update 操作）、還是刪除（Delete 操作）數據 X，都會直接在數據庫中增改刪。當然，如果應用執行的是修改或刪除操作，還會刪除緩存的數據 X。

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

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

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

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

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

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

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

如何解決數據不一致問題？

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

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

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

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

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

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

情況一：先刪除緩存，再更新數據庫。

假設線程 A 刪除緩存值后，還沒有來得及更新數據庫（比如說有網絡延遲），線程 B 就開始讀取數據了，那么這個時候，線程 B 會發現緩存缺失，就只能去數據庫讀取。這會帶來兩個問題：

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

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

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

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

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

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

這樣一來，其它線程讀取數據時，會發現緩存缺失，所以會從數據庫中讀取最新值。因為這個方案會在第一次刪除緩存值后，延遲一段時間再次進行刪除，所以我們也把它叫做“延遲雙刪”。

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

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

情況二：先更新數據庫值，再刪除緩存值。

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

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

好了，到這里，我們了解到了，緩存和數據庫的數據不一致一般是由兩個原因導致的，我給你提供了相應的解決方案。

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

推薦學習：Redis視頻教程