關(guān)于redis的延遲雙刪策略總結(jié)
redis延遲雙刪策略
1、什么是延遲雙刪？
延遲雙刪策略是分布式系統(tǒng)中數(shù)據(jù)庫存儲(chǔ)和緩存數(shù)據(jù)保持一致性的常用策略，但它不是強(qiáng)一致。其實(shí)不管哪種方案，都避免不了Redis存在臟數(shù)據(jù)的問題，只能減輕這個(gè)問題，要想徹底解決，得要用到同步鎖和對應(yīng)的業(yè)務(wù)邏輯層面解決。
2、為什么要進(jìn)行延遲雙刪？
一般我們在更新數(shù)據(jù)庫數(shù)據(jù)時(shí)，需要同步redis中緩存的數(shù)據(jù)
所以存在兩種方法：
- 第一種方案：先執(zhí)行update操作，再執(zhí)行緩存清除。
- 第二種方案：先執(zhí)行緩存清除，再執(zhí)行update操作。
這兩種方案的弊端是當(dāng)存在并發(fā)請求時(shí)
很容易出現(xiàn)以下問題：
- 第一種方案：當(dāng)請求1執(zhí)行update操作后，還未來得及進(jìn)行緩存清除，此時(shí)請求2查詢到并使用了redis中的舊數(shù)據(jù)。
- 第二種方案：當(dāng)請求1執(zhí)行清除緩存后，還未進(jìn)行update操作，此時(shí)請求2進(jìn)行查詢到了舊數(shù)據(jù)并寫入了redis。
3、如何實(shí)現(xiàn)延遲雙刪？
所以此時(shí)我們需要使用第三種方案：先進(jìn)行緩存清除，再執(zhí)行update，最后（延遲N秒）再執(zhí)行緩存清除。
4、需要注意的點(diǎn)
上述中（延遲N秒）的時(shí)間要大于一次寫操作的時(shí)間，一般為3-5秒。
原因：如果延遲時(shí)間小于寫入redis的時(shí)間，會(huì)導(dǎo)致請求1清除了緩存，但是請求2緩存還未寫入的尷尬。。。
ps:一般寫入的時(shí)間會(huì)遠(yuǎn)小于5秒
5、小結(jié)
延遲雙刪用比較簡潔的方式實(shí)現(xiàn) mysql 和 redis 數(shù)據(jù)最終一致性，但它不是強(qiáng)一致。
延遲，是因?yàn)?mysql 和 redis 主從節(jié)點(diǎn)數(shù)據(jù)同步不是實(shí)時(shí)的，所以需要等待一段時(shí)間，去增強(qiáng)它們的數(shù)據(jù)一致性。
延遲是指當(dāng)前請求邏輯處理延時(shí)，而不是當(dāng)前線程或進(jìn)程睡眠延遲。
mysql 和 redis 數(shù)據(jù)一致性是一個(gè)復(fù)雜的課題，通常是多種策略同時(shí)使用，例如：延遲雙刪、redis 過期淘汰、通過路由策略串行處理同類型數(shù)據(jù)、分布式鎖等等。
redis為什么要延時(shí)雙刪
首先，刪除緩存是為了讓其他事務(wù)讀取數(shù)據(jù)的時(shí)候不會(huì)讀到舊事務(wù)，而更新數(shù)據(jù)庫前清除緩存和更新數(shù)據(jù)庫后清除緩存解決的是不同時(shí)期的臟數(shù)據(jù)問題
只先刪緩存的話，當(dāng)我們在清除緩存和更新數(shù)據(jù)庫間有事務(wù)查詢緩存，此時(shí)沒有緩存，數(shù)據(jù)庫還沒更新，所以緩存又更新為舊數(shù)據(jù)了
只后刪緩存的話，在刪除緩存之前讀到的數(shù)據(jù)都是舊數(shù)據(jù)
那我們將兩者綜合起來的話，在更新前和更新后都進(jìn)行刪除，就可以很大程度上避免讀到臟數(shù)據(jù)
那為什么要延時(shí)雙刪呢？我們考慮這樣一種情況，在我們兩次刪除緩存之間更新數(shù)據(jù)庫之前，B事務(wù)讀到了數(shù)據(jù)庫中的臟數(shù)據(jù)，但是他的時(shí)間片耗盡了，結(jié)果更新數(shù)據(jù)庫的A事務(wù)進(jìn)行了第二次清空緩存，時(shí)間片輪轉(zhuǎn)回B時(shí)，B就會(huì)將舊數(shù)據(jù)緩存寫進(jìn)緩存當(dāng)中去。此時(shí)我們使用延時(shí)雙刪策略，延后第二次刪除緩存的時(shí)間，保證第二次刪除緩存在所有的舊緩存之后，就可以確保不會(huì)有舊數(shù)據(jù)出現(xiàn)了
但是我們思考延時(shí)雙刪策略，此策略只能保證最終一致性，保證了第二次刪除緩存之后的數(shù)據(jù)均為新數(shù)據(jù)，那第二次刪除緩存之前還是能夠讀到舊數(shù)據(jù)的，如果對于數(shù)據(jù)沒有強(qiáng)一致性要求的話延時(shí)雙刪已經(jīng)足夠了，但是如果對于數(shù)據(jù)有強(qiáng)一致性要求延時(shí)雙刪顯然就不滿足條件了，這個(gè)時(shí)候我們進(jìn)一步優(yōu)化的話可以考慮加鎖操作，在寫更新時(shí)阻塞讀操作，帶來的影響就是可以保證強(qiáng)一致性，但是吞吐量會(huì)下降
以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。
相關(guān)文章
本文主要介紹了Redis整合MySQL主從集群的示例代碼，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-09-09
解讀Redis秒殺優(yōu)化方案(阻塞隊(duì)列+基于Stream流的消息隊(duì)列)
該文章介紹了使用Redis的阻塞隊(duì)列和Stream流的消息隊(duì)列來優(yōu)化秒殺系統(tǒng)的方案,通過將秒殺流程拆分為兩條流水線,使用Redis緩存緩解數(shù)據(jù)庫壓力,并結(jié)合Lua腳本進(jìn)行原子性判斷,使用阻塞隊(duì)列和消息隊(duì)列異步處理訂單,有效提高了系統(tǒng)的并發(fā)處理能力和可用性2025-02-02
今天小編就為大家分享一篇解決redis修改requirepass后不生效的問題，具有很好的參考價(jià)值，希望對大家有所幫助。一起跟隨小編過來看看吧2018-05-05
銀河麒麟V10sp1服務(wù)器系統(tǒng)安裝redis不能使用的快速解決辦法
這篇文章主要介紹了銀河麒麟V10sp1服務(wù)器系統(tǒng)安裝redis不能使用的快速解決辦法,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2021-01-01
Redis實(shí)現(xiàn)好友關(guān)注的示例代碼
本文主要介紹了Redis實(shí)現(xiàn)好友關(guān)注的示例代碼，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-01-01
Redis實(shí)現(xiàn)延遲任務(wù)的三種方法詳解
延遲任務(wù)（Delayed Task）是指在未來的某個(gè)時(shí)間點(diǎn),執(zhí)行相應(yīng)的任務(wù),本文為大家整理了三種常見的實(shí)現(xiàn)方法,感興趣的小伙伴可以參考一下2025-04-04
緩存穿透是指當(dāng)用戶在查詢一條數(shù)據(jù)的時(shí)候，而此時(shí)數(shù)據(jù)庫和緩存卻沒有關(guān)于這條數(shù)據(jù)的任何記錄，而這條數(shù)據(jù)在緩存中沒找到就會(huì)向數(shù)據(jù)庫請求獲取數(shù)據(jù)。用戶拿不到數(shù)據(jù)時(shí)，就會(huì)一直發(fā)請求，查詢數(shù)據(jù)庫，這樣會(huì)對數(shù)據(jù)庫的訪問造成很大的壓力2022-07-07
Redis是一款性能強(qiáng)勁的內(nèi)存數(shù)據(jù)庫，但是在使用過程中，我們可能會(huì)遇到Big Key問題，這個(gè)問題就是Redis中某個(gè)key的value過大，所以Big Key問題本質(zhì)是Big Value問題，這篇文章主要介紹了Redis中的BigKey問題：排查與解決思路,需要的朋友可以參考下2023-03-03
Redis緩存的過期策略是保證緩存可靠性和性能的關(guān)鍵之一,本文主要介紹了Redis緩存過期的實(shí)現(xiàn)示例,具有一定的參考價(jià)值,感興趣的可以了解一下2023-12-12
這篇文章主要介紹了redis的持久化和緩存機(jī)制，具有很好的參考價(jià)值，希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2023-06-06