一、Redis 數(shù)據(jù)庫數(shù)據(jù)一致性的解決方案

在修改數(shù)據(jù)的時候，通常面臨著雙寫的問題，也就是redis中要更新數(shù)據(jù)，數(shù)據(jù)庫中也要更新數(shù)據(jù)，對于這個問題redis、數(shù)據(jù)庫的數(shù)據(jù)同步方案有四種：

1. 先更新Redis緩存，再更新數(shù)據(jù)庫
2. 先更新數(shù)據(jù)庫，再更新Redis緩存
3. 先刪除Redis中的緩存，再更新數(shù)據(jù)庫
4. 先更新數(shù)據(jù)庫，在刪除Redis緩存

從上面的解決方案來看，先不說Redis、數(shù)據(jù)庫的操作先后，數(shù)據(jù)庫的操作始終都是更新，但是Redis不一樣，Redis有兩種方案，一是更新（也就是直接在Redis中寫入更新的數(shù)據(jù)），二是刪除Redis中的緩存，那么接下來我們就看看這兩者有什么區(qū)別

1.1、更新Redis緩存、刪除Redis緩存的區(qū)別

更新Redis緩存

• 優(yōu)點：每次數(shù)據(jù)變化都及時更新緩存，所以查詢時不容易出現(xiàn)未命中的情況
• 缺點：更新緩存的消耗比較大。如果數(shù)據(jù)要經(jīng)過復(fù)雜的計算再寫入緩存，那么頻繁的更新緩存，就會影響服務(wù)器的性能。又因為Redis是單線程的，所以如果是寫入數(shù)據(jù)頻繁的業(yè)務(wù)場景，那么可能頻繁的更新緩存時，卻沒有多余的線程讀取該數(shù)據(jù)。

刪除Redis緩存

• 優(yōu)點：操作簡單，無論更新操作是否復(fù)雜，都是將緩存中的數(shù)據(jù)直接刪除
• 缺點：刪除緩存后，下一次查詢緩存會出現(xiàn)未命中，這時需要重新讀取一次數(shù)據(jù)庫。從上面的比較來看，一般情況下，刪除緩存是更有的方案

所以經(jīng)過這兩個區(qū)別的比較，我們只會采取刪除Redis緩存的兩個方案，接下來就是比較這兩個方案會產(chǎn)生什么樣的問題，哪一個方案產(chǎn)生的問題比較容易解決

二、先刪Redis緩存、后刪Redis緩存會產(chǎn)生什么問題？解決方案？

2.1、刪除Redis緩存，再更新數(shù)據(jù)庫

從上面的圖可以知道，如果更新數(shù)據(jù)庫失敗的話，那么即使刪除Redis緩存成功了，在重試期間，下一次讀取出來的數(shù)據(jù)還是之前的舊數(shù)據(jù)，即使重試成功了，數(shù)據(jù)庫的數(shù)據(jù)更新了，但是Redis中已經(jīng)被重新緩存了舊數(shù)據(jù)，這樣兩邊的數(shù)據(jù)就不會一致

2.2、解決方案

從上面的問題可以知道，問題就出現(xiàn)在進行修改數(shù)據(jù)庫重試期間，有線程訪問Redis，而此時Redis中沒有數(shù)據(jù)，就會從數(shù)據(jù)庫中拿數(shù)據(jù)，而此時的數(shù)據(jù)還是舊數(shù)據(jù)，就導(dǎo)致Redis重新緩存了舊數(shù)據(jù)，等重試成功之后導(dǎo)致數(shù)據(jù)庫跟Redis緩存數(shù)據(jù)不一致

這個問題的解決方案就是采用延遲雙刪的方案來解決

延遲雙刪的主要思想就是，在數(shù)據(jù)庫中的數(shù)據(jù)更新成功之后，再啟動一個延時線程來刪除Redis中的緩存，那么之后讀取的數(shù)據(jù)就是更新后的數(shù)據(jù)了，完整的流程應(yīng)該是：

1. 先刪一次Redis的緩存
2. 更新數(shù)據(jù)庫中的數(shù)據(jù)
3. 可以使用sleep方法讓線程睡一會
4. 然后再刪除一個Redis的緩存

2.3、先更新數(shù)據(jù)庫，再刪除Redis緩存

如上圖，是先更新數(shù)據(jù)庫再刪除緩存，在出現(xiàn)失敗時可能出現(xiàn)的問題：

• 線程A更新數(shù)據(jù)庫成功，線程A刪除緩存失?。?/li>
• 線程B讀取緩存成功，由于緩存刪除失敗，所以線程B讀取到的是緩存中舊的數(shù)據(jù)。
• 最后線程A刪除緩存成功，有別的線程訪問緩存同樣的數(shù)據(jù)，與數(shù)據(jù)庫中的數(shù)據(jù)是一樣。
• 最終，緩存和數(shù)據(jù)庫的數(shù)據(jù)是一致的，但是會有一些線程讀到舊的數(shù)據(jù)。

這個方案影響就會比較小一點，可以只采取重試機制就可以解決上面的問題，但是先刪除Redis緩存的那個方案不同，即使采取了重試機制過后，很有可能還是會產(chǎn)生數(shù)據(jù)不一致的情況，所以加了一個延遲雙刪的方案

比較兩個方案的誰更好

先刪除Redis的那個方案即使所有的操作都是成功的，但是在分布式場景下，有可能會導(dǎo)致高并發(fā)問題的產(chǎn)生，也就是說可能會在更新數(shù)據(jù)庫數(shù)據(jù)的同時有線程會訪問數(shù)據(jù)，這也就會導(dǎo)致數(shù)據(jù)不一致的問題

而先刪除數(shù)據(jù)庫則不一樣，即使在更新數(shù)據(jù)庫的時候發(fā)生了高并發(fā)問題也不影響，因為反正更新完數(shù)據(jù)庫之后還是會刪除Redis中的緩存，有影響的也僅僅只是在高并發(fā)產(chǎn)生的那部分線程而已，所以很明顯第二個方案影響更小

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論