redis延遲雙刪策略怎么使用

這篇文章主要講解了“redis延遲雙刪策略怎么使用”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“redis延遲雙刪策略怎么使用”吧！

在當前環境下，通常我們會首選redis緩存來減輕我們數據庫訪問壓力。但是也會遇到以下這種情況：大量用戶來訪問我們系統，首先會去查詢緩存， 如果緩存中沒有數據，則去查詢數據庫，然后更新數據到緩存中，并且如果數據庫中的數據發生了改變則需要同步到redis中，同步過程中需要保證 MySQL與redis數據一致性問題，在這個同步過程中出現短暫的數據延遲也是正常現象，但是最終需要保證mysql與緩存中的一致性。

//我們通常使用redis的邏輯
    //通常我們是先查詢reids
    String value = RedisUtils.get(key);
    if (!StringUtils.isEmpty(value)){
        return value;
    }
//從數據庫中獲取數據
    value = getValueForDb(key);
    if (!StringUtils.isEmpty(value)){
           RedisUtils.set(key,value);
        return value;
     }

1、什么是延遲雙刪？

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

2、為什么要進行延遲雙刪？

一般我們在更新數據庫數據時，需要同步redis中緩存的數據 所以我們一般會給出兩種方案：

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

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

但是這兩種方案在并發請求中容易出現以下問題

第一種方案弊端：當請求1去執行數據庫更新操作之后，還沒執行緩存清除時，請求2就進來了查詢了緩存，此時緩存中數據還是舊數據，還沒來得機刪除導致數據出現問題，但是當t1執行緩存刪除操作之后，后面的請求查詢不到緩存，再到數據中查詢，然后更新到緩存中，這種影響是比較小的

1. t1線程 先更新db；

2. t2線程查詢命中緩存 返回舊的數據；

3. 假設t1線程更新完db，預計5毫秒刪除完緩存key 在5毫秒內 其他線程查詢緩存結果還是為舊的數據，但是 5毫秒后查詢緩存結果是為空，在從新將db最新的結果同步到Redis中。

4. 一個項目中出現延遲是非常正常的，所以該情況發生的延遲對業務的影響其實很小。但是如果發生了，刪除緩存失敗呢？

1.不斷重試----如果是在http協議接口中 會導致接口響應變慢 調用該接口 會發生響應超時 2.或者通過mq異步的形式同步

第二種方案弊端：當請求1執行清除緩存后，還未執行數據更新操作的時，請求2進來查詢到數據庫的舊數據，并寫入了redis，這就導致了數據庫與redis數據不一致問題。

• t1線程先刪除緩存；

• t2線程讀取緩存為null，同步db數據到緩存中；

• t1線程更新db中的數據；

• t3線程查詢緩存中數據是舊數據；

3、對于方案處理都有弊端，那么我們需要使用延遲雙刪策略

先進行緩存清除，再執行update，最后（延遲N秒）再執行緩存清除。進行兩次刪除，且中間需要延遲一段時間

    RedisUtils.del(key);// 先刪除緩存    updateDB(user);// 更新db中的數據    Thread.sleep(N);// 延遲一段時間，在刪除該緩存key    RedisUtils.del(key);// 先刪除緩存

4、需要注意的點

上述中（延遲N秒）的時間要大于一次寫操作的時間。原因：如果延遲時間小于寫入redis的時間，會導致請求1清除了緩存，但是請求2緩存還未寫入的尷尬。。。

5、延遲的時間如何確定？

在業務程序運行時，統計業務邏輯執行讀數據和寫緩存的操作時間，以此為基礎來進行估算。因為這個方案會在第一次刪除緩存值后，延遲一段時間再次進行刪除，所以稱為“延遲雙刪”。

感謝各位的閱讀，以上就是“redis延遲雙刪策略怎么使用”的內容了，經過本文的學習后，相信大家對redis延遲雙刪策略怎么使用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！