Redis 键空间迭代 Scan

引言

在平时线上Redis维护工作中，有时候需要从Redis实例成千上万的key中找出特定前缀的key列表来手动处理数据，可能是修改他的值，也可能是删除key。

Redis提供了一个简单暴力的指令keys用来列出所有满足特定正则字符串规则的key。

127.0.0.1:6379> set codehole1 a 
OK
127.0.0.1:6379> set codehole2 b 
OK
127.0.0.1:6379> set codehole3 c 
OK
127.0.0.1:6379> set code1hole a 
OK
127.0.0.1:6379> set code2hole b 
OK
127.0.0.1:6379> set code3hole b 
OK
127.0.0.1:6379> keys *
1) "codehole1"
2) "code3hole"
3) "codehole3"
4) "code2hole"
5) "codehole2"
6) "code1hole"
127.0.0.1:6379> keys codehole* 
1) "codehole1"
2) "codehole3"
3) "codehole2"
127.0.0.1:6379> keys code*hole 
1) "code3hole"
2) "code2hole"
3) "code1hole"

这个指令使用很简单，提供一个简单的正则字符串即可，但是有明显的两个缺点

• 没有offset、limit参数，一次性吐出所有满足条件的key，万一实例中有几百w个key满足条件
• keys算法是遍历算法，复杂度为O(n)， 如果实例中有千万级以上的key，这个指令就会导致Redis服务卡顿，所有读写Redis的其他指令都会被延后甚至会超时报错。因为Redis是单线程程序，顺序执行所有指令，其他指令必须等到当前的keys指令执行完后才可以继续。

Redis为了解决这个问题，在2.8版本中引入了Scan指令，Scan相比keys具有以下特点：

• 复杂度也是O(n),但是他是通过游标分步进行的，不会阻塞线程。
• 提供limit参数，可以控制每次返回结果的最大条数，limit只是一个hint（优化提示），返回的结果可多可少。
• 同keys一样，他也可以提供模式匹配功能。
• 服务器不需要为游标保存状态，游标唯一状态就是scan返回给客户端的游标整数
• 返回的结果可能会有重复，需要客户端去重
• 遍历的过程中如果有数据修改，改动后的数据能不能遍历到是不确定的。
• 单次返回的结果是空的并不意味着遍历结束，而要看返回的游标值是否为零。

Scan基础使用

向Redis里插入10000条测试数据

import redis
client = redis.StrictRedis() 
for i in range(10000):client.set("key%d" % i, i)

目标找出以key99开头key列表。
scan参数提供了三个参数，分别是**cursor整数值；key的正则模式；遍历的limit hint**。第一次遍历时，cursor值为0，然后将返回结果中第一个整数值作为下一次遍历的cursor。一直遍历到返回的cursor值为0时结束。

127.0.0.1:6379> scan 0 match key99* count 1000 
1) "13976"
2) 1) "key9911" 2) "key9974" 3) "key9994"。。。。。。。
127.0.0.1:6379> scan 13976 match key99* count 1000 
。。。。
127.0.0.1:6379> scan 11687 match key99* count 1000 
1) "0" #返回的游标为0，表示遍历结束   

注意：虽然每次提供的limit是1000，但是返回的结果只有10个左右，因为这个limit不是限定返回结果的数量，而是限定服务器单次遍历的字典槽位数量（约等于）如果将limit设置为10，可能会发现返回的结果是空的，但是游标值不为0，意味着遍历还没结束。

字典的结构

在Redis中所有的key都存储在一个很大的字典中，这个字典的结构和Java中的HashMap一样，是数组+链表结构，第一维数组的大小总是2^n(n>=0),扩容一次数组大小空间加倍，也就是n++.

scan指令返回的游标就是第一维数组的位置索引，我们将这个位置索引称为槽（slot）。如果不考虑字典的扩容缩容，直接按数组下标挨个遍历即可。limit参数表示需要遍历的槽位数，之所以返回的结果可多可少，是因为不是所有的槽位上都会挂接链表，有些槽位可能是空的，还有些槽位挂接的链表上的元素可能有多个。每一次遍历都会将limit数量的槽位上挂接的所有链表元素进行模式匹配过滤后，一次性返回给客户端。

scan遍历顺序

scan的遍历顺序非常特别，他不是从第一维数组的第0位一直遍历到末尾，而是采用了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历，是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏。

普通加法和高位进位加法的区别
高位进位加法从左边加，进位往右边移动，同普通加法正好相反，但是最终他们都会遍历所有槽位并且没有重复。

假设当前二进制表示为000，则通过高位进位加法后是100（最高位加1，无进位）。在经过高位进位加是010（最高位加1，有进位，向右传递1）

字典扩容

Java中的HashMap有扩容的概念，当loadFactor达到阈值时，需要重新分配一个新的2倍大小的数组，然后将所有的元素全部rehash挂到新的数组下面。rehash就是将元素的hash值对数组长度进行取模运算，因为长度变了，所以每个元素挂接的槽位可能也发生了变化。又因为数组的长度是2^n次方，所以取模运算等价于位与操作。

位与操作（&）：对于每一对对应的位，如果两个对应位都是 1，则结果为 1，否则为 0。

假设当前字典的数组长度由8位扩容到16位，那么3号槽位011将会被rehash到3号槽位和11号槽位，也就是说该槽位链表中大约有一半的元素还是3号槽位，其他元素会放到11号槽位，11这个数字的二进制是1011，也就是对3的二进制011增加了一个高位1.

更抽象一点说，假设开始槽位的二进制数是xxx，那么该槽位中的元素将被rehash到0xxx或者1xxx(xxx+8)中。如果字典长度由16位扩容到32位，那么对于二进制槽位xxxx中的元素将被rehash到0xxxx和1xxxx中。

对比扩容缩容前后的遍历顺序

观察这张图，发现采用高位进位加法的遍历顺序，rehash后的槽位在遍历顺序上是相邻的。

假设当前即将遍历110这个位置，那么扩容后，当前槽位上的所有元素对应的新槽位是0110，1110，也就是在槽位的二进制数增加一个高位0或者1.这时，我们可以直接从0110这个槽位开始往后继续遍历，0110槽位之前的所有槽位都是已经遍历过的，这样就可以避免扩容后对已经遍历过的槽位进行重复遍历。

在考虑缩容，假设当前即将遍历110这个位置，那么缩容后，当前槽位所有的元素对应的新槽位是10，也就是去掉槽位二进制最高位。这时，我们可以直接从10这个槽位继续向后遍历，10槽位之前的所有槽位都是已经遍历过的。这样就可以避免缩容的重复遍历。不过缩容还是不太一样，他会对图中010这个槽位上的元素进行重复遍历，因为缩容后10槽位的元素是010和110上挂接的元素的融合。

渐进式rehash

Java中的HashMap在扩容时会一次性将旧数组下挂接的元素全部转移到新数组下面。如果HashMap中元素特别多，线程就会出现卡顿现象，Redis为了解决这个问题，采用渐进式rehash。

他会同时保留旧数组和新数组，然后在定时任务中以及后续对hash的指令操作中渐渐的将旧数组中挂接的元素迁移到新数组上。这意味着要操作处于rehash中的字典，需要同时访问新旧两个数组结构，如果在旧数组下面找不到元素，还需要去新数组下面寻找。

scan也需要考虑这个问题，对于rehash中的字典，需要同时扫描新旧槽位，然后将结果融合后返回给客户端。

更多的scan指令

scan指令是一系列指令，除了可以遍历所有的key之外，还可以对指定的容器集合进行遍历。比如zscan遍历zset集合元素，hscan遍历hash字典中的元素、sscan遍历set集合中的元素。

他们的原理同scan都会类似，因为hash底层就是字典，set也是一个特殊的hash（所有的value都指向同一个元素），zset内部也使用了字典来存储所有的元素内容。

大key扫描

有时候会因为业务人员使用不当，在Redis实例中会形成很大的对象，比如一个很大的hash，一个很大的zset这都是经常出现的。这样的对象对Redis的集群数据迁移带来了很大的问题，因为在集群环境下，如果某个key太大，会导致迁移卡顿。另外，在内存分配上，如果一个key太大，那么当他需要扩容时，会一次性申请更大的一块内存，这也会导致卡顿。如果这个大key被删除，内存会一次性回收，卡顿现象再次发生。

平时的业务开发中，要尽量避免大key的产生

如果观察到Redis的内存大起大落，这极有可能是因为大key导致的，这时候就需要定位出具体是哪个key，进一步定位出具体的业务来源，然后改进相关业务代码设计。

如何定位大key

为了避免对线上Redis带来卡顿，需要用到scan指令，对于扫描出来的每一个key，使用type指令获得key的类型，然后使用相应数据结构的size或者len方法来得到他的大小，对于每一种类型，保留大小的前N名作为扫描结果展示出来。
上面这样的过程需要编写脚本，比较繁琐，可以使用如下指令进行扫描。

redis-cli -h 127.0.0.1 -p 7001 –-bigkeys -i 0.1

–bigkeys: 这是一个特殊的参数，用于在 Redis 数据库中扫描并报告最大的键。这个功能可以帮助识别可能占用过多内存的键。

-i 0.1: 这个参数设置 redis-cli 命令的采样间隔，单位是秒。这里设置为 0.1 秒，意味着 redis-cli 在执行 --bigkeys 操作时每 0.1 秒采样一次，以减少对 Redis 服务器性能的影响。