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

在修改數(shù)據(jù)的時(shí)候，通常面臨著雙寫的問題，也就是redis中要更新數(shù)據(jù)，數(shù)據(jù)庫中也要更新數(shù)據(jù)，對(duì)于這個(gè)問題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)點(diǎn)：每次數(shù)據(jù)變化都及時(shí)更新緩存，所以查詢時(shí)不容易出現(xiàn)未命中的情況
• 缺點(diǎn)：更新緩存的消耗比較大。如果數(shù)據(jù)要經(jīng)過復(fù)雜的計(jì)算再寫入緩存，那么頻繁的更新緩存，就會(huì)影響服務(wù)器的性能。又因?yàn)镽edis是單線程的，所以如果是寫入數(shù)據(jù)頻繁的業(yè)務(wù)場景，那么可能頻繁的更新緩存時(shí)，卻沒有多余的線程讀取該數(shù)據(jù)。

刪除Redis緩存

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

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

二、先刪Redis緩存、后刪Redis緩存會(huì)產(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ù)就不會(huì)一致

2.2、解決方案

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

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

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

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

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

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

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

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

比較兩個(gè)方案的誰更好

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

而先刪除數(shù)據(jù)庫則不一樣，即使在更新數(shù)據(jù)庫的時(shí)候發(fā)生了高并發(fā)問題也不影響，因?yàn)榉凑峦陻?shù)據(jù)庫之后還是會(huì)刪除Redis中的緩存，有影響的也僅僅只是在高并發(fā)產(chǎn)生的那部分線程而已，所以很明顯第二個(gè)方案影響更小

總結(jié)

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

最新評(píng)論