本文基于社區(qū)版Redis 4.0.8

1、復(fù)現(xiàn)條件版本：

• 社區(qū)版Redis 4.0.10以下版本
• 使用場(chǎng)景：開啟讀寫分離的主從架構(gòu)或者集群架構(gòu)(master只負(fù)責(zé)寫流量，slave負(fù)責(zé)讀流量)

案例：

# 寫入一條帶過期時(shí)間10s的key
10.90.73.147:12345> set luxiu1 1 ex 10
OK
10.90.73.147:12345> get luxiu1
"1"
10.90.73.147:12345> exists luxiu1
(integer) 1
......
#等待10s，待key過期
......

10.90.73.147:12345> ttl luxiu1 
(integer) -2 #確定key已經(jīng)過期了
10.90.73.147:12345> get luxiu1
(nil)  #沒有問題，該key不存在了
10.90.73.147:12345> exists luxiu1
(integer) 1 #還能查到
10.90.73.147:12345> exists luxiu1
(integer) 1 #還能查到

2、源碼分析

在分析該問題前，需要了解Redis在讀寫分離模式下讀到過期數(shù)據(jù)的問題：

Redis過期key的刪除策略采用惰性刪除和定時(shí)刪除：

惰性刪除:主節(jié)點(diǎn)每次處理讀取命令時(shí)，都會(huì)檢查鍵是否超時(shí)，如果超時(shí)則執(zhí)行del命令刪除鍵對(duì)象，之后del命令也會(huì)異步發(fā)送給從節(jié)點(diǎn)。需要注意的是為了保證復(fù)制的一致性，從節(jié)點(diǎn)自身永遠(yuǎn)不會(huì)主動(dòng)刪除超時(shí)數(shù)據(jù)；

定時(shí)刪除:Redis主節(jié)點(diǎn)在內(nèi)部定時(shí)任務(wù)會(huì)循環(huán)采樣一定數(shù)量的鍵，當(dāng)發(fā)現(xiàn)采樣的鍵過期時(shí)執(zhí)行del命令，之后再同步給從節(jié)點(diǎn)；

如果此時(shí)數(shù)據(jù)大量過期，主節(jié)點(diǎn)采樣速度跟不上過期速度且主節(jié)點(diǎn)沒有讀取過期鍵的操作，那么從節(jié)點(diǎn)將無法收到del命令。這時(shí)在從節(jié)點(diǎn)上可以讀取到已經(jīng)超時(shí)的數(shù)據(jù)。Redis在3.2版本解決了這個(gè)問題，在從節(jié)點(diǎn)上讀取數(shù)據(jù)之前也會(huì)檢查鍵的過期時(shí)間來決定是否返回?cái)?shù)據(jù)。但是，4.0.10版本以下的exists命令實(shí)現(xiàn)方式有問題，導(dǎo)致該命令還是查詢到過期數(shù)據(jù)問題。

下面是4.0.10以下版本exists命令實(shí)現(xiàn)源碼：

問題就在于expireIfNeeded這個(gè)函數(shù)，它的功能就是惰性刪除，判斷如果key過期了就進(jìn)行del，我們是讀寫分離架構(gòu)，slave不進(jìn)行del，如下代碼：

直接返回1，并不進(jìn)行到del操作。

所以exists查詢到過期key一直存在。

3、問題解決

在社區(qū)版4.0.11以上版本已經(jīng)修復(fù)了該bug：

lookupKeyRead函數(shù)調(diào)用lookupKeyReadWithFlags(db,key,LOOKUP_NONE)lookupKeyReadWithFlags函數(shù)邏輯如下：

最后，可以升級(jí)到4.0.12版本解決該問題。

到此這篇關(guān)于Redis exists命令bug分析的文章就介紹到這了,更多相關(guān)Redis exists命令內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論