Redis 深度历险： 核心原理和应用实践2

1.应用 9：大海捞针 —— Scan 

在平时线上 Redis 维护工作中，有时候需要从 Redis 实例成千上万的 key 中找出特定
前缀的 key 列表来手动处理数据，可能是修改它的值，也可能是删除 key。这里就有一个问
题，如何从海量的 key 中找出满足特定前缀的 key 列表来

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

这个指令使用非常简单，提供一个简单的正则字符串即可，但是有很明显的两个缺点。 
1、没有 offset、limit 参数，一次性吐出所有满足条件的 key，万一实例中有几百 w 个 
key 满足条件，当你看到满屏的字符串刷的没有尽头时，你就知道难受了

2、keys 算法是遍历算法，复杂度是 O(n)，如果实例中有千万级以上的 key，这个指令
就会导致 Redis 服务卡顿，所有读写 Redis 的其它的指令都会被延后甚至会超时报错，因为 
Redis 是单线程程序，顺序执行所有指令，其它指令必须等到当前的 keys 指令执行完了才
可以继续。

Redis 为了解决这个问题，它在 2.8 版本中加入了大海捞针的指令——scan。scan 相比 
keys 具备有以下特点: 

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

scan 基础使用 

scan 参数提供了三个参数，第一个是 cursor 整数值，第二个是 key 的正则模式，第三
个是遍历的 limit hint。第一次遍历时，cursor 值为 0，然后将返回结果中第一个整数值作为
下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束

从上面的过程可以看到虽然提供的 limit 是 1000，但是返回的结果只有 10 个左右。因
为这个 limit 不是限定返回结果的数量，而是限定服务器单次遍历的字典槽位数量(约等于)。
如果将 limit 设置为 10，你会发现返回结果是空的，但是游标值不为零，意味着遍历还没结
束。

SCAN命令的有SCAN,SSCAN,HSCAN,ZSCAN。
SCAN的话就是遍历所有的keys
其他的SCAN命令的话是SCAN选中的集合。
SCAN命令是增量的循环，每次调用只会返回一小部分的元素。所以不会有KEYS命令的坑。
SCAN命令返回的是一个游标，从0开始遍历，到0结束遍历。
 

字典的结构 

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

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

scan 遍历顺序

scan 的遍历顺序非常特别。它不是从第一维数组的第 0 位一直遍历到末尾，而是采用
了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历，是考虑到字典的扩容和缩容
时避免槽位的遍历重复和遗漏
普通加法和高位进位加法的区别 
高位进位法从左边加，进位往右边移动，同普通加法正好相反。但是最终它们都会遍历
所有的槽位并且没有重复。

字典扩容 

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

渐进式 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 官方已经在 redis-cli 指令中提供
了这样的扫描功能，我们可以直接拿来即用。 
redis-cli -h 127.0.0.1 -p 7001 –-bigkeys 
如果你担心这个指令会大幅抬升 Redis 的 ops 导致线上报警，还可以增加一个休眠参
数。 
redis-cli -h 127.0.0.1 -p 7001 –-bigkeys -i 0.1 
上面这个指令每隔 100 条 scan 指令就会休眠 0.1s，ops 就不会剧烈抬升，但是扫描的
时间会变长

原理 1：鞭辟入里 —— 线程 IO 模型 

  Redis 是个单线程程序！这点必须铭记。 
也许你会怀疑高并发的 Redis 中间件怎么可能是单线程。很抱歉，它就是单线程，你的
怀疑暴露了你基础知识的不足。莫要瞧不起单线程，除了 Redis 之外，Node.js 也是单线
程，Nginx 也是单线程，但是它们都是服务器高性能的典范

原理 2：交头接耳 —— 通信协议

Redis 将所有数据都放在内存，用一个单线程对外提供服务，单个节点在跑满一个 CPU 核心的情
况下可以达到了 10w/s 的超高 QPS。 

以上2个原理不知道讲的啥,看不懂!!!

原理 3：未雨绸缪 —— 持久化 

 Redis 的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制
来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制。 
Redis 的持久化机制有两种，第一种是快照，第二种是 AOF 日志。快照是一次全量备
份，AOF 日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常

凑，而 AOF 日志记录的是内存数据修改的指令记录文本。AOF 日志在长期的运行过程中会
变的无比庞大，数据库重启时需要加载 AOF 日志进行指令重放，这个时间就会无比漫长。
所以需要定期进行 AOF 重写，给 AOF 日志进行瘦身。

快照原理 

我们知道 Redis 是单线程程序，这个线程要同时负责多个客户端套接字的并发读写操作
和内存数据结构的逻辑读写。 
在服务线上请求的同时，Redis 还需要进行内存快照，内存快照要求 Redis 必须进行文
件 IO 操作，可文件 IO 操作是不能使用多路复用 API。 
这意味着单线程同时在服务线上的请求还要进行文件 IO 操作，文件 IO 操作会严重拖
垮服务器请求的性能。还有个重要的问题是为了不阻塞线上的业务，就需要边持久化边响应
客户端请求。持久化的同时，内存数据结构还在改变，比如一个大型的 hash 字典正在持久
化，结果一个请求过来把它给删掉了，还没持久化完呢，这尼玛要怎么搞？ 
那该怎么办呢？ 
Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化，这个机制
很有意思，也很少人知道。多进程 COW 也是鉴定程序员知识广度的一个重要指标

fork(多进程)  

Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，快照持久化完全交给子进
程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代
码段和数据段。这时你可以将父子进程想像成一个连体婴儿，共享身体。这是 Linux 操作系
统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的
增长几乎没有明显变化

子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读
取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存
数据结构进行不间断的修改。 
这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操
作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复
制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，
还是进程产生时那一瞬间的数据子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再
也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安
心的遍历数据了进行序列化写磁盘了。 

AOF 原理

AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的
指令记录

假设 AOF 日志记录了自 Redis 实例创建以来所有的修改性指令序列，那么就可以通过
对一个空的 Redis 实例顺序执行所有的指令，也就是「重放」，来恢复 Redis 当前实例的内
存数据结构的状态

Redis 会在收到客户端修改指令后，先进行参数校验，如果没问题，就立即将该指令文
本存储到 AOF 日志中，也就是先存到磁盘，然后再执行指令。这样即使遇到突发宕机，已
经存储到 AOF 日志的指令进行重放一下就可以恢复到宕机前的状态。 
Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 
AOF 日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志瘦
身

AOF 重写 

Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其原理就是开辟一个子进
程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中。
序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加
完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了

fsync

AOF 日志是以文件的形式存在的，当程序对 AOF 日志文件进行写操作时，实际上是将
内容写到了内核为文件描述符分配的一个内存缓存中，然后内核会异步将脏数据刷回到磁盘
的。 
这就意味着如果机器突然宕机，AOF 日志内容可能还没有来得及完全刷到磁盘中，这个
时候就会出现日志丢失。那该怎么办？ 
Linux 的 glibc 提供了 fsync(int fd)函数可以将指定文件的内容强制从内核缓存刷到磁
盘。只要 Redis 进程实时调用 fsync 函数就可以保证 aof 日志不丢失。但是 fsync 是一个
磁盘 IO 操作，它很慢！如果 Redis 执行一条指令就要 fsync 一次，那么 Redis 高性能的
地位就不保了。 
所以在生产环境的服务器中，Redis 通常是每隔 1s 左右执行一次 fsync 操作，周期 1s 
是可以配置的。这是在数据安全性和性能之间做了一个折中，在保持高性能的同时，尽可能
使得数据少丢失

Redis 同样也提供了另外两种策略，一个是永不 fsync——让操作系统来决定合适同步磁
盘，很不安全，另一个是来一个指令就 fsync 一次——非常慢。但是在生产环境基本不会使
用，了解一下即可

运维

快照是通过开启子进程的方式进行的，它是一个比较耗资源的操作。 
    1、遍历整个内存，大块写磁盘会加重系统负载 
    2、AOF 的 fsync 是一个耗时的 IO 操作，它会降低 Redis 性能，同时也会增加系
统 IO 负担 

所以通常 Redis 的主节点是不会进行持久化操作，持久化操作主要在从节点进行。从节
点是备份节点，没有来自客户端请求的压力，它的操作系统资源往往比较充沛 ,

但是如果出现网络分区，从节点长期连不上主节点，就会出现数据不一致的问题，特别
是在网络分区出现的情况下又不小心主节点宕机了，那么数据就会丢失，所以在生产环境要
做好实时监控工作，保证网络畅通或者能快速修复。另外还应该再增加一个从节点以降低网
络分区的概率，只要有一个从节点数据同步正常，数据也就不会轻易丢失。

 Redis 4.0 混合持久化 

p106