redis延遲雙刪策略

1、什么是延遲雙刪？

延遲雙刪策略是分布式系統(tǒng)中數(shù)據(jù)庫存儲和緩存數(shù)據(jù)保持一致性的常用策略，但它不是強一致。其實不管哪種方案，都避免不了Redis存在臟數(shù)據(jù)的問題，只能減輕這個問題，要想徹底解決，得要用到同步鎖和對應(yīng)的業(yè)務(wù)邏輯層面解決。

2、為什么要進(jìn)行延遲雙刪？

一般我們在更新數(shù)據(jù)庫數(shù)據(jù)時，需要同步redis中緩存的數(shù)據(jù)

所以存在兩種方法：

• 第一種方案：先執(zhí)行update操作，再執(zhí)行緩存清除。
• 第二種方案：先執(zhí)行緩存清除，再執(zhí)行update操作。

這兩種方案的弊端是當(dāng)存在并發(fā)請求時

很容易出現(xiàn)以下問題：

• 第一種方案：當(dāng)請求1執(zhí)行update操作后，還未來得及進(jìn)行緩存清除，此時請求2查詢到并使用了redis中的舊數(shù)據(jù)。
• 第二種方案：當(dāng)請求1執(zhí)行清除緩存后，還未進(jìn)行update操作，此時請求2進(jìn)行查詢到了舊數(shù)據(jù)并寫入了redis。

3、如何實現(xiàn)延遲雙刪？

所以此時我們需要使用第三種方案：先進(jìn)行緩存清除，再執(zhí)行update，最后（延遲N秒）再執(zhí)行緩存清除。

4、需要注意的點

上述中（延遲N秒）的時間要大于一次寫操作的時間，一般為3-5秒。

原因：如果延遲時間小于寫入redis的時間，會導(dǎo)致請求1清除了緩存，但是請求2緩存還未寫入的尷尬。。。

ps:一般寫入的時間會遠(yuǎn)小于5秒

5、小結(jié)

延遲雙刪用比較簡潔的方式實現(xiàn) mysql 和 redis 數(shù)據(jù)最終一致性，但它不是強一致。

延遲，是因為 mysql 和 redis 主從節(jié)點數(shù)據(jù)同步不是實時的，所以需要等待一段時間，去增強它們的數(shù)據(jù)一致性。

延遲是指當(dāng)前請求邏輯處理延時，而不是當(dāng)前線程或進(jìn)程睡眠延遲。

mysql 和 redis 數(shù)據(jù)一致性是一個復(fù)雜的課題，通常是多種策略同時使用，例如：延遲雙刪、redis 過期淘汰、通過路由策略串行處理同類型數(shù)據(jù)、分布式鎖等等。 

redis為什么要延時雙刪

首先，刪除緩存是為了讓其他事務(wù)讀取數(shù)據(jù)的時候不會讀到舊事務(wù)，而更新數(shù)據(jù)庫前清除緩存和更新數(shù)據(jù)庫后清除緩存解決的是不同時期的臟數(shù)據(jù)問題

只先刪緩存的話，當(dāng)我們在清除緩存和更新數(shù)據(jù)庫間有事務(wù)查詢緩存，此時沒有緩存，數(shù)據(jù)庫還沒更新，所以緩存又更新為舊數(shù)據(jù)了

只后刪緩存的話，在刪除緩存之前讀到的數(shù)據(jù)都是舊數(shù)據(jù)

那我們將兩者綜合起來的話，在更新前和更新后都進(jìn)行刪除，就可以很大程度上避免讀到臟數(shù)據(jù)

那為什么要延時雙刪呢？我們考慮這樣一種情況，在我們兩次刪除緩存之間更新數(shù)據(jù)庫之前，B事務(wù)讀到了數(shù)據(jù)庫中的臟數(shù)據(jù)，但是他的時間片耗盡了，結(jié)果更新數(shù)據(jù)庫的A事務(wù)進(jìn)行了第二次清空緩存，時間片輪轉(zhuǎn)回B時，B就會將舊數(shù)據(jù)緩存寫進(jìn)緩存當(dāng)中去。此時我們使用延時雙刪策略，延后第二次刪除緩存的時間，保證第二次刪除緩存在所有的舊緩存之后，就可以確保不會有舊數(shù)據(jù)出現(xiàn)了

但是我們思考延時雙刪策略，此策略只能保證最終一致性，保證了第二次刪除緩存之后的數(shù)據(jù)均為新數(shù)據(jù)，那第二次刪除緩存之前還是能夠讀到舊數(shù)據(jù)的，如果對于數(shù)據(jù)沒有強一致性要求的話延時雙刪已經(jīng)足夠了，但是如果對于數(shù)據(jù)有強一致性要求延時雙刪顯然就不滿足條件了，這個時候我們進(jìn)一步優(yōu)化的話可以考慮加鎖操作，在寫更新時阻塞讀操作，帶來的影響就是可以保證強一致性，但是吞吐量會下降 

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

最新評論