异步编程规避Redis的阻塞（上）

1 简介

Redis重视影响Redis性能的因素，如：

• 命令操作
• 系统配置
• 关键机制
• 硬件配置 …

要尽可能避免性能异常场景，还要做好异常应对方案。影响Redis性能的潜在风险：

• Redis内部的阻塞式操作
• CPU核和NUMA架构的影响
• Redis关键系统配置
• Redis内存碎片
• Redis缓冲区

本文研究Redis内部的阻塞式操作及应对方案。

Redis的网络I/O和KV对读写都由主线程完成。若在主线程执行操作耗时太长，就会引起主线程阻塞。但Redis既有服务客户端请求的键值对增删改查操作，也有保证可靠性的持久化操作，还有主从复制时的数据同步操作。哪些会引起阻塞？

2 Redis的阻塞风险点

Redis要和不同对象交互，有着不同操作：

• 客户端 网络IO，KV对CRUD操作，DB操作
• 磁盘 生成RDB快照，记录AOF日志，AOF日志重写
• 主从节点 主库生成、传输RDB文件，从库接收RDB文件、清空数据库、加载RDB文件
• 切片集群实例 向其他实例传输哈希槽信息，数据迁移

2.1 客户端交互

网络I/O有时较慢，但Redis使用的I/O多路复用，避免了主线程一直处在等待网络连接或请求到来的状态，所以，网络I/O并非导致Redis阻塞因素。

2.1.1 集合全量查询和聚合操作

KV对的crud操作是Redis和客户端交互的主要部分，也是Redis主线程执行的主要任务。所以，复杂度高的crud操作势必阻塞Redis。

最基本标准，就是看操作复杂度是否为O(N)。Redis中涉及集合的操作复杂度通常为O(N)：

• 集合元素全量查询操作，如HGETALL、SMEMBERS
• 集合的聚合统计操作，如交、并差集

2.1.2 删除大key

集合自身的删除也可能阻塞。

不就是直接把数据删除，咋还能阻塞主线程？

删除操作的本质是释放KV对占用的内存空间。不要小瞧内存释放的过程。 释放内存只是第一步，为更加高效管理内存，应用程序释放内存时，os要把释放掉的内存块插入一个空闲内存块的链表，以便后续管理和再分配。这个过程本身需要时间，且会阻塞当前释放内存的应用程序。 所以，若突然释放大量内存，空闲内存块链表操作时间就会增加，就会造成Redis主线程阻塞。

那啥时释放大量内存呢？

就是在删除大量KV对数据时，最常见的就是删除包含大量元素的集合，即删除bigkey。 不同元素数量的集合在进行删除操作时所消耗的时间：

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

删除操作其实对Redis性能debuff很严重，在实际业务开发时还很容易被忽略。

2.1.3 清空数据库

同上，Redis的数据库级别操作中，清空数据库，如FLUSHDB、FLUSHALL等也是重大阻塞风险，涉及删除、释放所有KV对。