目录

一、Redis 实例有哪些阻塞点？

1. 和客户端交互时的阻塞点

1.1 查询

1.2 bigkey 删除操作

1.3 FLUSHDB 和 FLUSHALL

2. 和磁盘交互时的阻塞点

2.1 AOF 日志同步写(always)

3. 主从节点交互时的阻塞点

二、异步线程机制

三、哪些操作可以异步执行

什么是关键路径

四、异步的子线程机制

五、Redis的写操作（例如SET，HSET，SADD等）是在关键路径上吗？

Redis 性能的 5 大方面的潜在因素，

Redis 内部的阻塞式操作

CPU 核和 NUMA 架构的影响；

Redis 关键系统配置；

Redis 内存碎片；

Redis 缓冲区。

一、Redis 实例有哪些阻塞点？

客户端：网络 IO，键值对增删改查操作，数据库操作；

磁盘：生成 RDB 快照，记录 AOF 日志，AOF 日志重写；

主从节点：主库生成、传输 RDB 文件，从库接收 RDB 文件、清空数据库、加载 RDB 文件；

切片集群实例：向其他实例传输哈希槽信息，数据迁移。

?

1. 和客户端交互时的阻塞点

1.1 查询

集合全量查询和聚合操作。 例如hgetall、lrange key 0 -1、....

1.2bigkey 删除操作

删除操作的本质是要释放键值对占用的内存空间。你可不要小瞧内存的释放过程。释放内存只是第一步，为了更加高效地管理内存空间，在应用程序释放内存时，操作系统需要把释放掉的内存块插入一个空闲内存块的链表，以便后续进行管理和再分配。这个过程本身需要一定时间，而且会阻塞当前释放内存的应用程序，所以，如果一下子释放了大量内存，空闲内存块链表操作时间就会增加，相应地就会造成 Redis 主线程的阻塞。

测试了不同元素数量的集合在进行删除操作时所消耗的时间

?

从这张表里，我们可以得出三个结论：

1. 当元素数量从 10 万增加到 100 万时，4 大集合类型的删除时间的增长幅度从 5 倍上升到了近 20 倍；
2. 集合元素越大，删除所花费的时间就越长；
3. 当删除有 100 万个元素的集合时，最大的删除时间绝对值已经达到了 1.98s（Hash 类型）。Redis 的响应时间一般在微秒级别，所以，一个操作达到了近 2s，不可避免地会阻塞主线程。

1.3 FLUSHDB 和 FLUSHALL

2. 和磁盘交互时的阻塞点

2.1AOF 日志同步写(always)

Redis 直接记录 AOF 日志时，会根据不同的写回策略对数据做落盘保存。一个同步写(appendfsync always代表同步写)磁盘的操作的耗时大约是 1～2ms，如果有大量的写操作需要记录在 AOF 日志中，并同步写回的话，就会阻塞主线程了

3. 主从节点交互时的阻塞点

把 RDB 文件加载到内存，这个过程的快慢和 RDB 文件的大小密切相关，RDB 文件越大，加载过程越慢

二、异步线程机制

五个阻塞点：

1. 集合全量查询和聚合操作；
2. bigkey 删除；
3. 清空数据库；
4. AOF 日志同步写；
5. 从库加载 RDB 文件。

如果在主线程中执行这些操作，必然会导致主线程长时间无法服务其他请求。为了避免阻 塞式操作，Redis 提供了异步线程机制。

什么是异步线程机制？

Redis 会启动一些子线程，然后把一些任务交给这些子线程，让它们在后台完成，而不再由主线程来执行这 些任务。使用异步线程机制执行操作，可以避免阻塞主线程。

三、哪些操作可以异步执行

什么是关键路径

客户端把请求发送给 Redis 后，等着 Redis 返回数据结果的操作。

?

主线程接收到操作 1 后，因为操作 1 并不用给客户端返回具体的数据，所以，主线程可以把它交给后台子线程来完成，同时只要给客户端返回一个“OK”结果就行。在子线程执行操作 1 的时候，客户端又向 Redis 实例发送了操作 2，而此时，客户端是需要使用操作 2 返回的数据结果的，如果操作 2 不返回结果，那么，客户端将一直处于等待状态。

在这个例子中，

操作 1 就不算关键路径上的操作，因为它不用给客户端返回具体数据，所以可以由后台子线程异步执行。

操作 2 需要把结果返回给客户端，它就是关键路径上的操作，所以主线程必须立即把这个操作执行完。

五个阻塞点：

1. 集合全量查询和聚合操作；(关键路径)
2. bigkey 删除；
3. 清空数据库；
4. AOF 日志同步写；
5. 从库加载 RDB 文件。(关键路径)
6. 
   

由此可知，可以使用 Redis 的异步子线程机制来实现 bigkey 删除，清空数据库，以及 AOF 日志同步写。

四、异步的子线程机制

Redis 主线程启动后，会使用操作系统提供的 pthread_create 函数创建 3 个子线程，分别由它们负责 AOF 日志写操作、键值对删除以及文件关闭的异步执行。

redis]# pstree -p 2090
redis-server(2090)─┬─{redis-server}(2101)
                   ├─{redis-server}(2102)
                   └─{redis-server}(2103)

xxxxxxxxxxbr redis]# pstree -p 2090brredis-server(2090)─┬─{redis-server}(2101)br                   ├─{redis-server}(2102)br                   └─{redis-server}(2103)br

主线程通过一个链表形式的任务队列和子线程进行交互。当收到键值对删除和清空数据库的操作时，主线程会把这个操作封装成一个任务，放入到任务队列中，然后给客户端返回一个完成信息，表明删除已经完成。

但实际上，这个时候删除还没有执行，等到后台子线程从任务队列中读取任务后，才开始实际删除键值对，并释放相应的内存空间。因此，我们把这种异步删除也称为惰性删除（lazy free）。

AOF 日志配置成 everysec 选项后，主线程会把 AOF 写日志操作封装成一个任务，也放到任务队列中。后台子线程读取任务后，开始自行写入 AOF 日志，这样主线程就不用一直等待 AOF 日志写完了

?

Note : 异步的键值对删除和数据库清空操作是 Redis 4.0 后提供的功能

FLUSHDB ASYNC
FLUSHALL AYSNC

五、Redis的写操作（例如SET，HSET，SADD等）是在关键路径上吗？

1、如果客户端依赖操作返回值的不同，进而需要处理不同的业务逻辑，那么HSET和SADD操作算关键路径，而SET操作不算关键路径。因为HSET和SADD操作，如果field或member不存在时，Redis结果会返回1，否则返回0。而SET操作返回的结果都是OK，客户端不需要关心结果有什么不同。

2、如果客户端不关心返回值，只关心数据是否写入成功，那么SET/HSET/SADD不算关键路径，多次执行这些命令都是幂等的，这种情况下可以放到异步线程中执行。

3、但是有种例外情况，如果Redis设置了maxmemory，但是却没有设置淘汰策略，这三个操作也都算关键路径。因为如果Redis内存超过了maxmemory，再写入数据时，Redis返回的结果是OOM error，这种情况下，客户端需要感知有错误发生才行。

另外，我查阅了lazy-free相关的源码，发现有很多细节需要补充下：

1、lazy-free是4.0新增的功能，但是默认是关闭的，需要手动开启。

2、手动开启lazy-free时，有4个选项可以控制，分别对应不同场景下，要不要开启异步释放内存机制：
a) lazyfree-lazy-expire：key在过期删除时尝试异步释放内存
b) lazyfree-lazy-eviction：内存达到maxmemory并设置了淘汰策略时尝试异步释放内存
c) lazyfree-lazy-server-del：执行RENAME/MOVE等命令或需要覆盖一个key时，删除旧key尝试异步释放内存
d) replica-lazy-flush：主从全量同步，从库清空数据库时异步释放内存

3、即使开启了lazy-free，如果直接使用DEL命令还是会同步删除key，只有使用UNLINK命令才会可能异步删除key。

4、这也是最关键的一点，上面提到开启lazy-free的场景，除了replica-lazy-flush之外，其他情况都只是*可能*去异步释放key的内存，并不是每次必定异步释放内存的。

开启lazy-free后，Redis在释放一个key的内存时，首先会评估代价，如果释放内存的代价很小，那么就直接在主线程中操作了，没必要放到异步线程中执行（不同线程传递数据也会有性能消耗）。

什么情况才会真正异步释放内存？这和key的类型、编码方式、元素数量都有关系（详细可参考源码中的lazyfreeGetFreeEffort函数）：

a) 当Hash/Set底层采用哈希表存储（非ziplist/int编码存储）时，并且元素数量超过64个
b) 当ZSet底层采用跳表存储（非ziplist编码存储）时，并且元素数量超过64个
c) 当List链表节点数量超过64个（注意，不是元素数量，而是链表节点的数量，List的实现是在每个节点包含了若干个元素的数据，这些元素采用ziplist存储）

只有以上这些情况，在删除key释放内存时，才会真正放到异步线程中执行，其他情况一律还是在主线程操作。

也就是说String（不管内存占用多大）、List（少量元素）、Set（int编码存储）、Hash/ZSet（ziplist编码存储）这些情况下的key在释放内存时，依旧在主线程中操作。

可见，即使开启了lazy-free，String类型的bigkey，在删除时依旧有阻塞主线程的风险。所以，即便Redis提供了lazy-free，我建议还是尽量不要在Redis中存储bigkey。

个人理解Redis在设计评估释放内存的代价时，不是看key的内存占用有多少，而是关注释放内存时的工作量有多大。从上面分析基本能看出，如果需要释放的内存是连续的，Redis作者认为释放内存的代价比较低，就放在主线程做。如果释放的内存不连续（大量指针类型的数据），这个代价就比较高，所以才会放在异步线程中去执行。

?