需求

有時候因為 Redis Key 沒有設(shè)置過期時間或者因為業(yè)務(wù)需求或者Redis內(nèi)存不足或者修改Redis Key值等需求，并且這些Key是有規(guī)律的，可以通過正則表達式來匹配。

解決方法一

一般通過網(wǎng)上搜索，會告訴你使用下面方法，Redis 提供了一個簡單暴力的指令 keys用來列出所有滿足特定正則字符串規(guī)則的 key。

$ redis-cli --raw keys "testkey-*" | xargs redis-cli del 

通過 Redis keys 來匹配你需要刪除的key，再使用 xargs 把結(jié)果傳給 redis-cli del ，這樣看似完美，實則有很大風(fēng)險。

上面命令使用非常簡單，提供一個簡單的正則字符串即可，但是有很明顯的兩個缺點。

• 沒有 offset、limit 參數(shù)，一次性吐出所有滿足條件的 key，萬一實例中有幾百 w 個 key 滿足條件，當(dāng)你看到滿屏的字符串刷的沒有盡頭時，你就知道難受了。
• keys 算法是遍歷算法，復(fù)雜度是 O(n)，如果實例中有千萬級以上的 key，這個指令就會導(dǎo)致 Redis 服務(wù)卡頓，所有讀寫 Redis 的其它的指令都會被延后甚至?xí)瑫r報錯，因為 Redis 6 版本以下都是單線程程序，順序執(zhí)行所有指令，其它指令必須等到當(dāng)前的 keys 指令執(zhí)行完了才可以繼續(xù)，這樣就會導(dǎo)致業(yè)務(wù)不可用，甚至造成redis宕機的風(fēng)險。

注意：這種方法不推薦，建議生產(chǎn)環(huán)境屏蔽keys命令。那大家會問，有沒有更好的方法來解決這個問題?答案是當(dāng)然用，請接著看下文。

解決方法二

Redis從2.8版本開始支持 scan 命令，SCAN命令的基本用法如下：

SCAN cursor [MATCH pattern] [COUNT count] 

• cursor：游標(biāo)，SCAN命令是一個基于游標(biāo)的迭代器，SCAN命令每次被調(diào)用之后，都會向用戶返回一個新的游標(biāo)，用戶在下次迭代時需要使用這個新游標(biāo)作為SCAN命令的游標(biāo)參數(shù)，以此來延續(xù)之前的迭代過程，直到服務(wù)器向用戶返回值為0的游標(biāo)時，一次完整的遍歷過程就結(jié)束了。
• MATCH：匹配規(guī)則，例如遍歷以 testkey- 開頭的所有key可以寫成 testkey-*。
• COUNT：COUNT選項的作用就是讓用戶告知迭代命令，在每次迭代中應(yīng)該從數(shù)據(jù)集里返回多少元素，COUNT只是對增量式迭代命令的一種提示，并不代表真正返回的數(shù)量，例如你COUNT設(shè)置為2有可能會返回3個元素，但返回的元素數(shù)據(jù)會與COUNT設(shè)置的正相關(guān)，COUNT的默認(rèn)值是10。

例子：

$ scan 0 MATCH testkey-* 
 
1) "34" 
2)  1) "testkey-2" 
    2) "testkey-49" 
    3) "testkey-20" 
    4) "testkey-19" 
    5) "testkey-93" 
    6) "testkey-8" 
    7) "testkey-34" 
    8) "testkey-76" 
    9) "testkey-13" 
   10) "testkey-18" 
   11) "testkey-10" 
 
$ scan 34 MATCH testkey-* COUNT 1000 
 
1) "0" 
2)  1) "ops-coffee-16" 
    2) "ops-coffee-19" 
    3) "ops-coffee-23" 
    4) "ops-coffee-21" 
    5) "ops-coffee-40" 
    6) "ops-coffee-22" 
    7) "ops-coffee-1" 
    8) "ops-coffee-11" 
    9) "ops-coffee-28" 
   10) "ops-coffee-3" 
   11) "ops-coffee-26" 
   12) "ops-coffee-4" 
   13) "ops-coffee-31" 
   ... 

scan 命令返回的是一個包含兩個元素的數(shù)組，第一個數(shù)組元素是用于進行下一次迭代的新游標(biāo)，而第二個數(shù)組元素則是一個數(shù)組，這個數(shù)組中包含了所有被迭代的元素。

上面這個例子的意思是掃描所有前綴為testkey-的key。第一次迭代使用0作為游標(biāo)，表示開始一次新的迭代，同時使用了MATCH匹配前綴為testkey-的key，返回了游標(biāo)值34以及遍歷到的數(shù)據(jù)。第二次迭代使用的是第一次迭代時返回的游標(biāo)，也即是命令回復(fù)第一個元素的值34，同時通過將COUNT選項的參數(shù)設(shè)置為1000，強制命令為本次迭代掃描更多元素。在第二次調(diào)用SCAN命令時，命令返回了游標(biāo)0，這表示迭代已經(jīng)結(jié)束，整個數(shù)據(jù)集已經(jīng)被完整遍歷過了。

Redis scan 命令就是基于游標(biāo)的迭代器，意味著命令每次被調(diào)用都需要使用上一次這個調(diào)用返回的游標(biāo)作為該次調(diào)用的游標(biāo)參數(shù)，以此來延續(xù)之前的迭代過程。當(dāng)SCAN命令的游標(biāo)參數(shù)被設(shè)置為0時，服務(wù)器將開始一次新的迭代，而當(dāng)redis服務(wù)器向用戶返回值為0的游標(biāo)時，表示迭代已結(jié)束，這是唯一迭代結(jié)束的判定方式，而不能通過返回結(jié)果集是否為空判斷迭代結(jié)束。

上面的需求，最終可以使用下面命令來解決：

$ redis-cli --scan --pattern "testkey-*" | xargs -L 1000 redis-cli del 

xargs -L 指令表示xargs一次讀取的行數(shù)，也就是每次刪除key的數(shù)量，不要一次行讀取太多數(shù)量key。

scan 與 keys 比較

scan 相比 keys 具備有以下特點:

• 復(fù)雜度雖然也是 O(n)，但是它是通過游標(biāo)分步進行的，不會阻塞線程。
• 提供 limit 參數(shù)，可以控制每次返回結(jié)果的最大條數(shù)，limit 只是對增量式迭代命令的一種提示(hint)，返回的結(jié)果可多可少。
• 同 keys 一樣，它也提供模式匹配功能。
• 服務(wù)器不需要為游標(biāo)保存狀態(tài)，游標(biāo)的唯一狀態(tài)就是 scan 返回給客戶端的游標(biāo)整數(shù)。
• 返回的結(jié)果可能會有重復(fù)，需要客戶端去重復(fù)，這點非常重要。
• 遍歷的過程中如果有數(shù)據(jù)修改，改動后的數(shù)據(jù)能不能遍歷到是不確定的。
• 單次返回的結(jié)果是空的并不意味著遍歷結(jié)束，而要看返回的游標(biāo)值是否為零。

小結(jié)

Redis 類似 scan 命令還有很多，比如：

• scan 指令是一系列指令，除了可以遍歷所有的 key 之外，還可以對指定的容器集合進行遍歷
• zscan 遍歷 zset 集合元素
• hscan 遍歷 hash 字典的元素
• sscan 遍歷 set 集合的元素

注意：SSCAN 命令、 HSCAN 命令和 ZSCAN 命令的第一個參數(shù)總是一個數(shù)據(jù)庫鍵。而 SCAN 命令則不需要在第一個參數(shù)提供任何數(shù)據(jù)庫鍵，因為它迭代的是當(dāng)前數(shù)據(jù)庫中的所有數(shù)據(jù)庫鍵。

參考鏈接

http://jinguoxing.github.io/redis/2018/09/04/redis-scan/

https://juejin.cn/post/6844903869412016142