Redis 中 scan 命令太坑了,千萬別亂用!!

作者:鉑賽東
鏈接:www.jianshu.com/p/8cf8aac3dc25

1

原本以爲自己對redis命令還蠻熟悉的,各種數據模型各種基於redis的騷操作。但是最近在使用redis的scan的命令式卻踩了一個坑,頓時發覺自己原來對redis的遊標理解的很有限。所以記錄下這個踩坑的過程,背景如下:

公司因爲redis服務器內存喫緊,需要刪除一些無用的沒有設置過期時間的key。大概有500多w的key。雖然key的數目聽起來挺嚇人。但是自己玩redis也有年頭了,這種事還不是手到擒來?

當時想了下,具體方案是通過lua腳本來過濾出500w的key。然後進行刪除動作。lua腳本在redis server上執行,執行速度快,執行一批只需要和redis server建立一次連接。篩選出來key,然後一次刪1w。然後通過shell腳本循環個500次就能刪完所有的。以前通過lua腳本做過類似批量更新的操作,3w一次也是秒級的。基本不會造成redis的阻塞。這樣算起來,10分鐘就能搞定500w的key。

然後,我就開始直接寫lua腳本。首先是篩選。

用過redis的人,肯定知道redis是單線程作業的,肯定不能用keys命令來篩選,因爲keys命令會一次性進行全盤搜索,會造成redis的阻塞,從而會影響正常業務的命令執行。

500w數據量的key,只能增量迭代來進行。redis提供了scan命令,就是用於增量迭代的。這個命令可以每次返回少量的元素,所以這個命令十分適合用來處理大的數據集的迭代,可以用於生產環境。

scan命令會返回一個數組,第一項爲遊標的位置,第二項是key的列表。如果遊標到達了末尾,第一項會返回0。

2

所以我寫的第一版的lua腳本如下:

local c = 0
local resp = redis.call('SCAN',c,'MATCH','authToken*','COUNT',10000)
c = tonumber(resp[1])
local dataList = resp[2]

for i=1,#dataList do
    local d = dataList[i]
    local ttl = redis.call('TTL',d)
    if ttl == -1 then
        redis.call('DEL',d)
    end
end

if c==0 then
  return 'all finished'
else
  return 'end'
end

在本地的測試redis環境中,通過執行以下命令mock了20w的測試數據:

eval "for i = 1, 200000 do redis.call('SET','authToken_' .. i,i) end" 0

然後執行script load命令上傳lua腳本得到SHA值,然後執行evalsha去執行得到的SHA值來運行。具體過程如下:

我每刪1w數據,執行下dbsize(因爲這是我本地的redis,裏面只有mock的數據,dbsize也就等同於這個前綴key的數量了)。

奇怪的是,前面幾行都是正常的。但是到了第三次的時候,dbsize變成了16999,多刪了1個,我也沒太在意,但是最後在dbsize還剩下124204個的時候,數量就不動了。之後無論再執行多少遍,數量還依舊是124204個。

隨即我直接運行scan命令:

發現遊標雖然沒有到達末尾,但是key的列表卻是空的。

這個結果讓我懵逼了一段時間。我仔細檢查了lua腳本,沒有問題啊。難道是redis的scan命令有bug?難道我理解的有問題?

我再去翻看redis的命令文檔對count選項的解釋:

經過詳細研讀,發現count選項所指定的返回數量還不是一定的,雖然知道可能是count的問題,但無奈文檔的解釋實在難以很通俗的理解,依舊不知道具體問題在哪

3

後來經過某個小夥伴的提示,看到了另外一篇對於scan命令count選項通俗的解釋:

看完之後恍然大悟。原來count選項後面跟的數字並不是意味着每次返回的元素數量,而是scan命令每次遍歷字典槽的數量

我scan執行的時候每一次都是從遊標0的位置開始遍歷,而並不是每一個字典槽裏都存放着我所需要篩選的數據,這就造成了我最後的一個現象:雖然我count後面跟的是10000,但是實際redis從開頭往下遍歷了10000個字典槽後,發現沒有數據槽存放着我所需要的數據。所以我最後的dbsize數量永遠停留在了124204個。

所以在使用scan命令的時候,如果需要迭代的遍歷,需要每次調用都需要使用上一次這個調用返回的遊標作爲該次調用的遊標參數,以此來延續之前的迭代過程。

至此,心中的疑惑就此解開,改了一版lua:

local c = tonumber(ARGV[1])
local resp = redis.call('SCAN',c,'MATCH','authToken*','COUNT',10000)
c = tonumber(resp[1])
local dataList = resp[2]

for i=1,#dataList do
    local d = dataList[i]
    local ttl = redis.call('TTL',d)
    if ttl == -1 then
        redis.call('DEL',d)
    end
end

return c

在本地上傳後執行:

可以看到,scan命令沒法完全保證每次篩選的數量完全等同於給定的count,但是整個迭代卻很好的延續下去了。最後也得到了遊標返回0,也就是到了末尾。至此,測試數據20w被全部刪完。

這段lua只要在套上shell進行循環就可以直接在生產上跑了。經過估算大概在12分鐘左右能刪除掉500w的數據。

知其然,知其所以然。雖然scan命令以前也曾玩過。但是的確不知道其中的細節。況且文檔的翻譯也不是那麼的準確,以至於自己在面對錯誤的結果時整整浪費了近1個多小時的時間。記錄下來,加深理解。

另外,關注公衆號Java技術棧,在後臺回覆:面試,可以獲取我整理的 Redis 系列面試題和答案,非常齊全。

近期熱文推薦:

1.600+ 道 Java面試題及答案整理(2021最新版)

2.終於靠開源項目弄到 IntelliJ IDEA 激活碼了,真香!

3.阿里 Mock 工具正式開源,幹掉市面上所有 Mock 工具!

4.Spring Cloud 2020.0.0 正式發佈,全新顛覆性版本!

5.《Java開發手冊(嵩山版)》最新發布,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章