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

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

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

案例：

# 寫入一條帶過期時間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的刪除策略采用惰性刪除和定時刪除：

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

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

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

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

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

直接返回1，并不進行到del操作。

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

3、問題解決

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

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

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

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

最新評論