redis keys与scan差别 redis keys与scan命令的区别说明

redis keys和scan的区别

redis的keys命令，通常在用来删除相关key时使用，但这个命令有一个弊端，在redis拥有数百万及以上的keys时，执行速度会比较慢，更致命的是，这个命令会阻塞redis多路复用的io主线程，如果这个线程阻塞，在此期间，其他发向redis服务端的命令，都会被阻塞，从而引发一系列级联反应，导致瞬间相应卡顿，从而引发超时等问题，所以应该在生产环境禁止用使用keys和类似的命令smembers，这种时间复杂度为O（N），且会阻塞主线程的命令，是非常危险的。

如果在生产环境上，我们有需要查找然后删除key的需求，我们应该使用scan命令，来替代key。scan也是O(N)复杂度，支持通配查找key的命令，不同keys的是它采用的是游标按批次迭代返回数据，可以不用阻塞主线程。

scan：渐进式遍历键

SCAN cursor [MATCH pattern] [COUNT count]

scan 参数提供了三个参数（6.0后增加了一个type参数,具体看官方文档），第一个是 cursor 整数值(hash桶的索引值)，第二个是 key 的正则模式，第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。

第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为下一次遍历的 cursor。

一直遍历到返回的 cursor 值为 0 时结束。

使用案例如下：

从运行结果，我们可以看出几个问题：

虽然我们指定了扫描的count是10，但它实际扫描出来的数量不一定是10

scan他可能遍历出重复的key

这边解释一下，为什么扫描出来得数量不一定是10。这是因为match实际上相当于过滤器的作用，所以scan其实是先扫描10个元素出来，然后再根据pattern一过滤，那么剩下来的满足条件元素就可能没有10个了，甚至可能一个都没有。

此外呢，如果在scan的过程中有键的变化（增加、删除、修改），那么新增的键可能不会被遍历出来，即scan不能保证完整的遍历出所有的键，这是我们开发的时候需要考虑的。

关于更多的细节，比如为什么新增的键可能不能被遍历出来，等我后面更深入的学习了redis底层的数据结构在回来补充。

总之，对于redis的大数量操作，很难做到很精确。

补充：redis模糊查询keys和scan的比较和用法

一、keys

1、语法

keys pattern 

2、说明

redis中允许模糊查询的有3个通配符，分别是：*，?，[]

*：通配任意多个字符

?：通配单个字符

[]：通配括号内的某一个字符

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 游标 MATCH <给定模式相匹配的元素> count 每次迭代所返回的元素数量 ，SCAN 命令是增量的循环，每次调用只会返回一小部分的元素。scan会返回两个结果，一个是用于下次遍历的游标，一个是结果集；

SCAN 命令是一个基于游标的迭代器（cursor based iterator）： SCAN 命令每次被调用之后， 都会向用户返回一个新的游标， 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程。

当 SCAN 命令的游标参数被设置为 0 时， 服务器将开始一次新的迭代， 而当服务器向用户返回值为 0 的游标时， 表示迭代已结束

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里面的所有数据可以用 `keys `这样的指令来实现。但是存在一个问题就是这样做的话，在数据量很大的情况下效率是很不理想的；

2、Keys模糊匹配，请大家在实际运用的时候忽略掉。因为Keys会引发Redis锁，并且增加Redis的CPU占用，情况是很恶劣的；如果数据庞大的话可能需要几秒或更长，对于生产服务器上锁定几秒这绝对是灾难了；

3、新的命令SCAN出现，它可以帮助我们解决因为用keys遍历大数据量的数据库而导致服务器阻塞的情况，因为它每次都只便利一小部分数据，每次操作对应的时间复杂度是O(1)；

以上为个人经验，希望能给大家一个参考，也希望大家多多支持。如有错误或未考虑完全的地方，望不吝赐教。