SCAN命令是一个基于游标的迭代器。这意味着命令每次被调用都需要使用上一次这个调用返回的游标作为该次调用的游标参数，以此来延续之前的迭代过程。
这里使用scan 0 match key1111* count 20命令来完成这个查询，稍显意外的是，使用一开始都没有查询到结果，这个要从scan命令的原理来看。
scan在遍历key的时候，0就代表第一次，key1111*代表按照key1111开头的模式匹配，count 20中的20并不是代表输出符合条件的key，而是限定服务器单次遍历的字典槽位数量(约等于)。
那么，什么又叫做槽的数据？这个槽是不是Redis集群中的slot？答案是否定的。其实上图已经给出了答案了。
如果上面说的“字典槽”的数量是集群中的slot，又知道集群中的slot数量是16384，那么遍历16384个槽之后，必然能遍历出来所有的key信息，
上面清楚地看到，当遍历的字典槽的数量20000的时候，游标依旧没有走完遍历结果，因此这个字典槽并不等于集群中的slot的概念。
经过测试，在scan的时候，究竟遍历多大的COUNT值能完全match到符合条件的key，跟具体对象的key的个数有关，
如果以超过key个数的count来scan，必定会一次性就查找到所有符合条件的key，比如在key个数为10W个的情况下，一次遍历20w个字典槽，肯定能完全遍历出来结果。
我们的Redis中有3个key，我们每次只遍历一个一维数组中的元素。如上所示，SCAN命令的遍历顺序是
0->2->1->3
这个顺序看起来有些奇怪。我们把它转换成二进制就好理解一些了。
00->10->01->11
我们发现每次这个序列是高位加1的。普通二进制的加法，是从右往左相加、进位。而这个序列是从左往右相加、进位的。这一点我们在redis的源码中也得到印证。
在dict.c文件的dictScan函数中对游标进行了如下处理
v = rev(v);
v++;
v = rev(v);
复制代码意思是，将游标倒置，加一后，再倒置，也就是我们所说的“高位加1”的操作。
这里大家可能会有疑问了，为什么要使用这样的顺序进行遍历，而不是用正常的0、1、2……这样的顺序呢，这是因为需要考虑遍历时发生字典扩容与缩容的情况（不得不佩服开发者考虑问题的全面性）。
我们来看一下在SCAN遍历过程中，发生扩容时，遍历会如何进行。加入我们原始的数组有4个元素，也就是索引有两位，这时需要把它扩充成3位，并进行rehash。
原来挂接在xx下的所有元素被分配到0xx和1xx下。在上图中，当我们即将遍历10时，dict进行了rehash，这时，scan命令会从010开始遍历，而000和100（原00下挂接的元素）不会再被重复遍历。
再来看看缩容的情况。假设dict从3位缩容到2位，当即将遍历110时，dict发生了缩容，这时scan会遍历10。这时010下挂接的元素会被重复遍历，但010之前的元素都不会被重复遍历了。所以，缩容时还是可能会有些重复元素出现的。
相比于keys命令，scan命令有两个比较明显的优势：
- scan命令的时间复杂度虽然也是O(N)，但它是分次进行的，不会阻塞线程。
- scan命令提供了limit参数，可以控制每次返回结果的最大条数。
这两个优势就帮助我们解决了上面的难题，不过scan命令也并不是完美的，它返回的结果有可能重复，因此需要客户端去重。至于为什么会重复，相信你看完本文之后就会有答案了。
关于scan命令的基本用法，可以参看Redis命令详解：Keys一文中关于SCAN命令的介绍。
今天我们主要从底层的结构和源码的角度来讨论scan是如何工作的。
作者：面向Google编程
链接：https://juejin.im/post/5bbcc8325188255c74553ae3
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。