Redis从海量key里查询出某一固定前缀的key

引入问题:
常规的查找key,使用的是KEYS pattern 查找所有符合给定模式pattern的key
但使用keys命令在海量数据下是有问题的

1. keys指令一次性返回所有匹配的key
2. 键的数量过大会造成服务的卡顿, 需要等很久才会返回结果.

从海量key里查询出某一固定前缀的key 主要用到了SCAN 命令 ,该命令的格式如下:
SCAN cursor [MATCH pattern] [COUNT count]
cursor 为游标, 即从哪里开始查找, 第一次查找时,传入0.
MATCH pattern 为查找的条件
count 为返回的个数, 虽然这里可以填写返回的个数, 但是真实返回的数量是不可控的, 只能是大概率的返回符合count的参数.

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

当 SCAN 命令的游标参数被设置为 0 时， 服务器将开始一次新的迭代， 而当服务器向用户返回值为 0 的游标时， 表示迭代已结束。一次返回的数量不可控, 只能是大概率的符合count参数

演示代码如下, 查询以k1位开头的key.

127.0.0.1:6379> scan 0 match k1* count 10
1) "917504"
2) 1) "k1068846"
   2) "k1174741"
   3) "k136682"
   4) "k1003555"
   5) "k1035818"
   6) "k1102763"
127.0.0.1:6379> scan 917504 match k1* count 10
1) "1769472"
2) 1) "k1043323"
   2) "k1416983"
   3) "k1108522"
   4) "k1029273"
   5) "k1383074"
127.0.0.1:6379> scan 1769472 match k1* count 10
1) "1212416"
2) 1) "k1515282"
   2) "k1213114"

在上面这个例子中， 第一次迭代使用 0 作为游标， 表示开始一次新的迭代。

第二次迭代使用的是第一次迭代时返回的游标， 也即是命令回复第一个元素的值 —— 917504 。

从上面的示例可以看到， SCAN 命令的回复是一个包含两个元素的数组， 第一个数组元素是用于进行下一次迭代的新游标， 而第二个数组元素则是一个数组， 这个数组中包含了所有被迭代的元素。

如果调用 SCAN 命令时， 命令返回了游标 0 ， 这表示迭代已经结束， 整个数据集（collection）已经被完整遍历过了。

以 0 作为游标开始一次新的迭代， 一直调用 SCAN 命令， 直到命令返回游标 0 ， 我们称这个过程为一次完整遍历（full iteration）。

参考文章
http://doc.redisfans.com/key/scan.html