redis keys和scan的區(qū)別

redis的keys命令，通常在用來刪除相關(guān)key時使用，但這個命令有一個弊端，在redis擁有數(shù)百萬及以上的keys時，執(zhí)行速度會比較慢，更致命的是，這個命令會阻塞redis多路復(fù)用的io主線程，如果這個線程阻塞，在此期間，其他發(fā)向redis服務(wù)端的命令，都會被阻塞，從而引發(fā)一系列級聯(lián)反應(yīng)，導(dǎo)致瞬間相應(yīng)卡頓，從而引發(fā)超時等問題，所以應(yīng)該在生產(chǎn)環(huán)境禁止用使用keys和類似的命令smembers，這種時間復(fù)雜度為O（N），且會阻塞主線程的命令，是非常危險的。

如果在生產(chǎn)環(huán)境上，我們有需要查找然后刪除key的需求，我們應(yīng)該使用scan命令，來替代key。scan也是O(N)復(fù)雜度，支持通配查找key的命令，不同keys的是它采用的是游標(biāo)按批次迭代返回數(shù)據(jù)，可以不用阻塞主線程。

scan：漸進(jìn)式遍歷鍵

SCAN cursor [MATCH pattern] [COUNT count]

scan 參數(shù)提供了三個參數(shù)（6.0后增加了一個type參數(shù),具體看官方文檔），第一個是 cursor 整數(shù)值(hash桶的索引值)，第二個是 key 的正則模式，第三個是一次遍歷的key的數(shù)量(參考值，底層遍歷的數(shù)量不一定)，并不是符合條件的結(jié)果數(shù)量。

第一次遍歷時，cursor 值為 0，然后將返回結(jié)果中第一個整數(shù)值作為下一次遍歷的 cursor。

一直遍歷到返回的 cursor 值為 0 時結(jié)束。

使用案例如下：

從運行結(jié)果，我們可以看出幾個問題：

雖然我們指定了掃描的count是10，但它實際掃描出來的數(shù)量不一定是10

scan他可能遍歷出重復(fù)的key

這邊解釋一下，為什么掃描出來得數(shù)量不一定是10。這是因為match實際上相當(dāng)于過濾器的作用，所以scan其實是先掃描10個元素出來，然后再根據(jù)pattern一過濾，那么剩下來的滿足條件元素就可能沒有10個了，甚至可能一個都沒有。

此外呢，如果在scan的過程中有鍵的變化（增加、刪除、修改），那么新增的鍵可能不會被遍歷出來，即scan不能保證完整的遍歷出所有的鍵，這是我們開發(fā)的時候需要考慮的。

關(guān)于更多的細(xì)節(jié)，比如為什么新增的鍵可能不能被遍歷出來，等我后面更深入的學(xué)習(xí)了redis底層的數(shù)據(jù)結(jié)構(gòu)在回來補充。

總之，對于redis的大數(shù)量操作，很難做到很精確。

補充：redis模糊查詢keys和scan的比較和用法

一、keys

1、語法

keys pattern 

2、說明

redis中允許模糊查詢的有3個通配符，分別是：*，?，[]

*：通配任意多個字符

?：通配單個字符

[]：通配括號內(nèi)的某一個字符

3、操作

192.168.230.21:6379[2]> set hello 1
OK
192.168.230.21:6379[2]> set word 1
OK
192.168.230.21:6379[2]> set hellp 1
OK
192.168.230.21:6379[2]> set ahellog 1
OK
192.168.230.21:6379[2]> set hellog 1
OK
192.168.230.21:6379[2]> keys *
1) "hello"
2) "hellog"
3) "hellp"
4) "word"
5) "ahellog"
192.168.230.21:6379[2]> keys *hell*
1) "hello"
2) "hellog"
3) "hellp"
4) "ahellog"
192.168.230.21:6379[2]> keys hell*
1) "hello"
2) "hellog"
3) "hellp"
//知道前面的一些字母，忘記了最后一個字母
192.168.230.21:6379[2]> keys hell?
1) "hello"
2) "hellp"
//知道前面的一些字母，忘記了最后兩個個字母
192.168.230.21:6379[2]> keys hell??
1) "hellog"
//知道前面四個字母，最后一個字母有可能是p t y 其中的一個
192.168.230.21:6379[2]> keys hell[pty]
1) "hellp"
192.168.230.21:6379[2]> 

二、scan

1、語法

SCAN cursor [MATCH pattern] [COUNT count]

2、說明

scan 游標(biāo) MATCH 給定模式相匹配的元素> count 每次迭代所返回的元素數(shù)量 ，SCAN 命令是增量的循環(huán)，每次調(diào)用只會返回一小部分的元素。scan會返回兩個結(jié)果，一個是用于下次遍歷的游標(biāo)，一個是結(jié)果集；

SCAN 命令是一個基于游標(biāo)的迭代器（cursor based iterator）： SCAN 命令每次被調(diào)用之后， 都會向用戶返回一個新的游標(biāo)， 用戶在下次迭代時需要使用這個新游標(biāo)作為 SCAN 命令的游標(biāo)參數(shù)， 以此來延續(xù)之前的迭代過程。

當(dāng) SCAN 命令的游標(biāo)參數(shù)被設(shè)置為 0 時， 服務(wù)器將開始一次新的迭代， 而當(dāng)服務(wù)器向用戶返回值為 0 的游標(biāo)時， 表示迭代已結(jié)束

3、操作

192.168.230.21:6379[2]> keys *
1) "hello"
2) "hellog"
3) "hellp"
4) "word"
5) "ahellog"
192.168.230.21:6379[2]> scan 0 match *ll* count 2
1) "5"
2) 1) "hellp"
 2) "hello"
192.168.230.21:6379[2]> scan 5 match *ll* count 2
1) "0"
2) 1) "hellog"
 2) "ahellog"
192.168.230.21:6379[2]> 

三、性能對比

1、我們在獲取redis里面的某個db里面的所有數(shù)據(jù)可以用 `keys `這樣的指令來實現(xiàn)。但是存在一個問題就是這樣做的話，在數(shù)據(jù)量很大的情況下效率是很不理想的；

2、Keys模糊匹配，請大家在實際運用的時候忽略掉。因為Keys會引發(fā)Redis鎖，并且增加Redis的CPU占用，情況是很惡劣的；如果數(shù)據(jù)龐大的話可能需要幾秒或更長，對于生產(chǎn)服務(wù)器上鎖定幾秒這絕對是災(zāi)難了；

3、新的命令SCAN出現(xiàn)，它可以幫助我們解決因為用keys遍歷大數(shù)據(jù)量的數(shù)據(jù)庫而導(dǎo)致服務(wù)器阻塞的情況，因為它每次都只便利一小部分?jǐn)?shù)據(jù)，每次操作對應(yīng)的時間復(fù)雜度是O(1)；

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。