redis數(shù)據(jù)一致性之延時雙刪策略詳解

更新時間：2023年09月05日 11:11:27 作者：無形風

在使用redis時,需要保持redis和數(shù)據(jù)庫數(shù)據(jù)的一致性,最流行的解決方案之一就是延時雙刪策略,今天我們就來詳細刨析一下,需要的朋友可以參考下

注意：要知道經(jīng)常修改的數(shù)據(jù)表不適合使用redis，因為雙刪策略執(zhí)行的結果是把redis中保存的那條數(shù)據(jù)刪除了，以后的查詢就都會去查詢數(shù)據(jù)庫。所以redis使用的是讀遠遠大于改的數(shù)據(jù)緩存。

1，首先要理解在并發(fā)環(huán)境下redis數(shù)據(jù)一致性的問題所在

在多線程并發(fā)情況下，假設有兩個數(shù)據(jù)庫修改請求，為保證數(shù)據(jù)庫與redis的數(shù)據(jù)一致性，
修改請求的實現(xiàn)中需要修改數(shù)據(jù)庫后，級聯(lián)修改redis中的數(shù)據(jù)。
請求一：1.1修改數(shù)據(jù)庫數(shù)據(jù)		1.2 修改redis數(shù)據(jù)
請求二：2.1修改數(shù)據(jù)庫數(shù)據(jù)		2.2 修改redis數(shù)據(jù)
并發(fā)情況下就會存在1.1 ---> 2.1 ---> 2.2 ---> 1.2的情況 
（一定要理解線程并發(fā)執(zhí)行多組原子操作執(zhí)行順序是可能存在交叉現(xiàn)象的）
此時存在的問題就是：
	1.1修改數(shù)據(jù)庫的數(shù)據(jù)最終保存到了redis中，2.1在1.1之后也修改了數(shù)據(jù)庫數(shù)據(jù)。
	此時出現(xiàn)了redis中數(shù)據(jù)和數(shù)據(jù)庫數(shù)據(jù)不一致的情況，在后面的查詢過程中就會長時間去先查redis，
	從而出現(xiàn)查詢到的數(shù)據(jù)并不是數(shù)據(jù)庫中的真實數(shù)據(jù)的嚴重問題。
問題解決：
	修改數(shù)據(jù)庫級聯(lián)修改redis數(shù)據(jù)改為  修改數(shù)據(jù)庫數(shù)據(jù)后級聯(lián)刪除redis數(shù)據(jù)
	至于是先執(zhí)行1.2的redis刪除，還是限制性2.2的redis刪除，無關緊要。
	結果都是redis中數(shù)據(jù)已被刪除。之后的查詢就會由于redis中沒有數(shù)據(jù)而去查數(shù)據(jù)庫，
	此時即不會存在查詢到的數(shù)據(jù)和數(shù)據(jù)庫的數(shù)據(jù)不一致的情況。

2，上面詳解了redis數(shù)據(jù)一致性的問題所在，并提供了單刪策略來解決問題但此時依然存在比較嚴重的問題。

上面的單刪策略情況如下：
修改請求的實現(xiàn)中需要修改數(shù)據(jù)庫后，級聯(lián)刪除redis中的數(shù)據(jù)。
請求一：1.1修改數(shù)據(jù)庫數(shù)據(jù)		1.2 刪除redis數(shù)據(jù)
請求二：2.1修改數(shù)據(jù)庫數(shù)據(jù)		2.2 刪除redis數(shù)據(jù)
假設現(xiàn)在并發(fā)存在一個查詢請求
請求三：3.1查詢redis中數(shù)據(jù)   3.2查詢數(shù)據(jù)庫數(shù)據(jù)    3.3 新查到的數(shù)據(jù)寫入redis
（一定要理解帶redis的查詢請求實現(xiàn)邏輯，先查redis，數(shù)據(jù)不存在查數(shù)據(jù)庫，
			查到的數(shù)據(jù)寫入redis以便以后的查詢不去直接查數(shù)據(jù)庫）
此時并發(fā)情況下就會存在1.1 ---> 1.2 ---> 3.1 ---> 3.2 ---> 2.1 ---> 2.2 ---> 3.3的情況 
此時存在的問題就是：
	此時數(shù)據(jù)庫中的數(shù)據(jù)保存的是2.1修改后的數(shù)據(jù)，而redis中保存的數(shù)據(jù)是3.2中在1.1修改數(shù)據(jù)后的結果，
	此時出現(xiàn)了redis中數(shù)據(jù)和數(shù)據(jù)庫數(shù)據(jù)不一致的情況，在后面的查詢過程中就會長時間去先查redis，
	從而出現(xiàn)查詢到的數(shù)據(jù)并不是數(shù)據(jù)庫中的真實數(shù)據(jù)的嚴重問題。

3，上面刨析到了單刪策略來解決redis數(shù)據(jù)一致性存在的問題，下面我們來說雙刪策略

上面的單刪策略存在問題的情況如下：
請求一：1.1修改數(shù)據(jù)庫數(shù)據(jù)		1.2 刪除redis數(shù)據(jù)
請求二：2.1修改數(shù)據(jù)庫數(shù)據(jù)		2.2 刪除redis數(shù)據(jù)
請求三：3.1查詢redis中數(shù)據(jù)   3.2查詢數(shù)據(jù)庫數(shù)據(jù)    3.3 新查到的數(shù)據(jù)寫入redis
添加延時雙刪策略后的情況
請求一：1.1修改數(shù)據(jù)庫數(shù)據(jù)		1.2 刪除redis數(shù)據(jù)    1.3 延時3--5s再去刪除redis中數(shù)據(jù)
請求二：2.1修改數(shù)據(jù)庫數(shù)據(jù)		2.2 刪除redis數(shù)據(jù)    2.3 延時3--5s再去刪除redis中數(shù)據(jù)
請求三：3.1查詢redis中數(shù)據(jù)     3.2 查詢數(shù)據(jù)庫數(shù)據(jù)    3.3 新查到的數(shù)據(jù)寫入redis
雙刪策略為什么能解決問題：
因為存在了延時時間，故1.3或2.3 一定是最后執(zhí)行的一步操作（并發(fā)中的延時一定要理解）
延時的根本目的就是為了讓程序先把3.3執(zhí)行完，再去刪除redis

4，如何實現(xiàn)延時3–5s的操作

比較好的：   項目整合quartz等定時任務框架，去實現(xiàn)延時3--5s再去執(zhí)行最后一步任務
比較一般的：  創(chuàng)建線程池，線程池中拿一個線程，線程體中延時3-5s再去執(zhí)行最后一步任務（不能忘了啟動線程）
比較差的：   單獨創(chuàng)建一個線程去實現(xiàn)延時執(zhí)行

到此這篇關于redis數(shù)據(jù)一致性之延時雙刪詳解的文章就介紹到這了,更多相關redis延時雙刪內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: