2023-07-03：講一講Redis緩存的數(shù)據(jù)一致性問(wèn)題和處理方案。

答案2023-07-03：

當(dāng)使用緩存時(shí)，無(wú)論是在本地內(nèi)存中緩存還是使用 Redis 等外部緩存系統(tǒng)，會(huì)引入數(shù)據(jù)同步的問(wèn)題。下面以 Tomcat 向 MySQL 中進(jìn)行數(shù)據(jù)的插入、更新和刪除操作為例，來(lái)說(shuō)明具體的過(guò)程。

【資料圖】

分析下面幾種解決方案的數(shù)據(jù)同步方案：

1.先更新緩存，再更新數(shù)據(jù)庫(kù)：先更新緩存可以提高讀取性能，但如果更新緩存成功而更新數(shù)據(jù)庫(kù)失敗，可能導(dǎo)致數(shù)據(jù)不一致。

2.先更新數(shù)據(jù)庫(kù)，再更新緩存：確保數(shù)據(jù)的持久性，但如果更新數(shù)據(jù)庫(kù)成功而更新緩存失敗，也可能導(dǎo)致數(shù)據(jù)不一致。

3.先刪除緩存，后更新數(shù)據(jù)庫(kù)：通過(guò)先刪除緩存，再更新數(shù)據(jù)庫(kù)的方式，可以在數(shù)據(jù)更新后保證數(shù)據(jù)的一致性，但會(huì)降低讀取操作的性能。

4.先更新數(shù)據(jù)庫(kù)，后刪除緩存：確保數(shù)據(jù)的持久性，并在更新數(shù)據(jù)庫(kù)成功后再刪除緩存，以保持?jǐn)?shù)據(jù)的一致性。

對(duì)于新增數(shù)據(jù)的情況，數(shù)據(jù)會(huì)直接寫入數(shù)據(jù)庫(kù)，無(wú)需對(duì)緩存進(jìn)行操作。在這種情況下，緩存中本身就沒(méi)有新增數(shù)據(jù)，而數(shù)據(jù)庫(kù)中保存的是最新值。因此，緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)是一致的。

我們通常不考慮這個(gè)方案，因?yàn)榇嬖谝韵聠?wèn)題：即使在更新緩存成功后，若出現(xiàn)更新數(shù)據(jù)庫(kù)時(shí)的異常，會(huì)導(dǎo)致緩存中的數(shù)據(jù)與數(shù)據(jù)庫(kù)數(shù)據(jù)完全不一致。由于緩存數(shù)據(jù)一直存在，這種不一致性很難察覺(jué)到。

我們一般不考慮先更新數(shù)據(jù)庫(kù)再更新緩存的方案，與第一個(gè)方案存在相同的問(wèn)題。數(shù)據(jù)庫(kù)更新成功但緩存更新失敗時(shí)，仍然會(huì)導(dǎo)致數(shù)據(jù)不一致的問(wèn)題。此外，這種方案還存在以下問(wèn)題：

并發(fā)問(wèn)題：當(dāng)有請(qǐng)求A和請(qǐng)求B同時(shí)進(jìn)行更新操作時(shí)，可能出現(xiàn)以下情況：線程A先更新數(shù)據(jù)庫(kù)，然后線程B也更新了數(shù)據(jù)庫(kù)，隨后線程B更新了緩存，最后線程A也更新了緩存。這導(dǎo)致了請(qǐng)求A應(yīng)該先更新緩存，但由于網(wǎng)絡(luò)等原因，請(qǐng)求B卻比請(qǐng)求A更早更新了緩存，從而產(chǎn)生臟數(shù)據(jù)。

業(yè)務(wù)場(chǎng)景問(wèn)題：如果寫數(shù)據(jù)庫(kù)的操作比讀數(shù)據(jù)的操作更頻繁，采用這種方案會(huì)導(dǎo)致數(shù)據(jù)還沒(méi)有被讀取，就頻繁更新緩存，從而浪費(fèi)性能。

除了更新緩存，我們還可以考慮刪除緩存的方案。具體選擇更新緩存還是淘汰緩存取決于“更新緩存的復(fù)雜度”。如果更新緩存的成本較低，我們更傾向于更新緩存以提高緩存命中率；而如果更新緩存的代價(jià)較高，我們則更傾向于淘汰緩存。

該方案也會(huì)出問(wèn)題，具體出現(xiàn)的原因如下。

1、此時(shí)來(lái)了兩個(gè)請(qǐng)求，請(qǐng)求 A（更新操作） 和請(qǐng)求 B（查詢操作）

2、請(qǐng)求 A 會(huì)先刪除 Redis 中的數(shù)據(jù)，然后去數(shù)據(jù)庫(kù)進(jìn)行更新操作；

3、此時(shí)請(qǐng)求 B 看到 Redis 中的數(shù)據(jù)時(shí)空的，會(huì)去數(shù)據(jù)庫(kù)中查詢?cè)撝?，補(bǔ)錄到 Redis 中；

4、但是此時(shí)請(qǐng)求 A 并沒(méi)有更新成功，或者事務(wù)還未提交，請(qǐng)求B去數(shù)據(jù)庫(kù)查詢得到舊值；

5、那么這時(shí)候就會(huì)產(chǎn)生數(shù)據(jù)庫(kù)和 Redis 數(shù)據(jù)不一致的問(wèn)題。

如何解決呢？其實(shí)最簡(jiǎn)單的解決辦法就是延時(shí)雙刪的策略。就是

（1）先淘汰緩存

（2）再寫數(shù)據(jù)庫(kù)

（3）休眠1秒，再次淘汰緩存

這段偽代碼就是“延遲雙刪”

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

這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。

那么，這個(gè)1秒怎么確定的，具體該休眠多久呢？

針對(duì)上面的情形，讀該自行評(píng)估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。然后寫數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請(qǐng)求結(jié)束，寫請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

但是上述的保證事務(wù)提交完以后再進(jìn)行刪除緩存還有一個(gè)問(wèn)題，就是如果你使用的是** Mysql ****的讀寫分離的架構(gòu)**的話，那么其實(shí)主從同步之間也會(huì)有時(shí)間差。

此時(shí)來(lái)了兩個(gè)請(qǐng)求，請(qǐng)求 A（更新操作） 和請(qǐng)求 B（查詢操作）

請(qǐng)求 A 更新操作，刪除了Redis，

請(qǐng)求主庫(kù)進(jìn)行更新操作，主庫(kù)與從庫(kù)進(jìn)行同步數(shù)據(jù)的操作，

請(qǐng) B 查詢操作，發(fā)現(xiàn) Redis中沒(méi)有數(shù)據(jù)，

去從庫(kù)中拿去數(shù)據(jù)，此時(shí)同步數(shù)據(jù)還未完成，拿到的數(shù)據(jù)是舊數(shù)據(jù)。

此時(shí)的解決辦法有兩個(gè)：

1、還是使用雙刪延時(shí)策略。只是，睡眠時(shí)間修改為在主從同步的延時(shí)時(shí)間基礎(chǔ)上，加幾百ms。

2、就是如果是對(duì) Redis進(jìn)行填充數(shù)據(jù)的查詢數(shù)據(jù)庫(kù)操作，那么就強(qiáng)制將其指向主庫(kù)進(jìn)行查詢。

繼續(xù)深入，采用這種同步淘汰策略，吞吐量降低怎么辦？

那就將第二次刪除作為異步的。自己起一個(gè)線程，異步刪除。這樣，寫的請(qǐng)求就不用沉睡一段時(shí)間后了，再返回。這么做，加大吞吐量。

繼續(xù)深入，第二次刪除,如果刪除失敗怎么辦？

所以，我們引出了，下面的第四種策略，先更新數(shù)據(jù)庫(kù)，再刪緩存。

Cache Aside模式是一種常用的緩存處理方式。在讀取數(shù)據(jù)時(shí)，先檢查緩存，如果緩存中存在數(shù)據(jù)，則直接返回；如果緩存中不存在，則從數(shù)據(jù)庫(kù)中讀取，并將數(shù)據(jù)寫入緩存，最后返回響應(yīng)。在更新數(shù)據(jù)時(shí)，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。

通常情況下，我們更傾向于使用刪除緩存的操作，因?yàn)閯h除緩存的速度比在數(shù)據(jù)庫(kù)中更新數(shù)據(jù)的速度更快，能更有效地避免數(shù)據(jù)不一致的問(wèn)題。通過(guò)延時(shí)雙刪的處理方式，可以進(jìn)一步減少緩存不一致性的可能性。

標(biāo)簽：