前言：Redis 6.0.1 于 2020 年 5 月 2 日正式发布了，如 Redis 作者 antirez 所说，这是迄今为止最“企业”化的版本，也是有史以来改动最大的一个 Redis 版本。这个版本提供了诸多令人心动的新特性及功能改进，比如新网络协议RESP3，新的集群代理，ACL等，其中关注度比较高的应该是多线程模型了。

---

1、Redis6.0之前的版本真的是单线程吗？

Redis在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。但如果严格来讲从Redis4.0之后并不是单线程，除了主线程外，它也有后台线程在处理一些较为缓慢的操作，例如清理脏数据、无用连接的释放、大 key 的删除等等。

其中执行命令阶段，由于 Redis 是单线程来处理命令的，所有每一条到达服务端的连接不会立刻执行，所有的连接都会进入一个 Socket 队列中，当 socket 可读则交给单线程事件分发器逐个被执行。如下图所示：

---

2、Redis6.0之前为什么一直不使用多线程？

官方曾做过类似问题的回复：使用Redis时，几乎不存在CPU成为瓶颈的情况， Redis主要受限于内存和网络。例如在一个普通的Linux系统上，Redis通过使用pipelining每秒可以处理100万个请求，所以如果应用程序主要使用O(N)或O(log(N))的命令，它几乎不会占用太多CPU。

使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis通过AE事件模型以及IO多路复用等技术，处理性能非常高，因此没有必要使用多线程。单线程机制使得 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。

为什么说Redis的瓶颈不在CPU？

Redis绝大部分操作是基于内存的，而且是纯kv（key-value）操作，所以命令执行速度非常快。我们可以大概理解成，redis中的数据存储在一张大HashMap中，HashMap的优势就是查找和写入的时间复杂度都是O(1)。Redis内部采用这种结构存储数据，就奠定了Redis高性能的基础。根据Redis官网描述，在理想情况下Redis每秒可以提交一百万次请求，每次请求提交所需的时间在纳秒的时间量级。既然每次的Redis操作都这么快，单线程就可以完全搞定了，那还何必要用多线程呢！

---

3、Redis6.0为什么要引入多线程呢？

Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理80,000到100,000 QPS，这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。

但随着越来越复杂的业务场景，有些公司动不动就上亿的交易量，因此需要更大的QPS。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器，但该方案有非常大的缺点，例如要管理的Redis服务器太多，维护代价大；某些适用于单个Redis服务器的命令不适用于数据分区；数据分区无法解决热点读/写问题；数据偏斜，重新分配和放大/缩小变得更加复杂等等。

从Redis自身角度来说，因为读写网络的read/write系统调用占用了Redis执行期间大部分CPU时间，瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

• 提高网络 IO 性能，典型的实现比如使用 DPDK 来替代内核网络栈的方式
• 使用多线程充分利用多核，典型的实现比如 Memcached。

协议栈优化的这种方式跟 Redis 关系不大，支持多线程是一种最有效最便捷的操作方式。所以总结起来，redis支持多线程主要就是两个原因：

• 可以充分利用服务器 CPU 资源，目前主线程只能利用一个核
• 多线程任务可以分摊 Redis 同步 IO 读写负荷

---

4、Redis6.0默认是否开启了多线程？

Redis6.0的多线程默认是禁用的，只使用主线程。如需开启需要修改redis.conf配置文件：io-threads-do-reads yes

---

5、Redis6.0多线程开启时，线程数如何设置？

开启多线程后，还需要设置线程数，否则是不生效的。同样修改redis.conf配置文件

关于线程数的设置，官方有一个建议：4核的机器建议设置为2或3个线程，8核的建议设置为6个线程，线程数一定要小于机器核数。还需要注意的是，线程数并不是越大越好，官方认为超过了8个基本就没什么意义了。

---

6、Redis6.0采用多线程后，性能的提升效果如何？

Redis 作者 antirez 在 RedisConf 2019分享时曾提到：Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云esc进行过测试，GET/SET 命令在4线程 IO时性能相比单线程是几乎是翻倍了。

测试环境：

Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 内存，主机型号 ecs.ic5.2xlarge

Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 内存，主机型号 ecs.ic5.2xlarge

测试结果：

详见：正式支持多线程！Redis 6.0与老版性能对比评测 - 知乎

说明1：这些性能验证的测试并没有针对严谨的延时控制和不同并发的场景进行压测。数据仅供验证参考而不能作为线上指标。

说明2：如果开启多线程，至少要4核的机器，且Redis实例已经占用相当大的CPU耗时的时候才建议采用，否则使用多线程没有意义。所以估计80%的公司开发人员看看就好。

---

7、Redis6.0多线程的实现机制？

 流程简述如下：

1、主线程负责接收建立连接请求，获取 socket 放入全局等待读处理队列
2、主线程处理完读事件之后，通过 RR(Round Robin) 将这些连接分配给这些 IO 线程
3、主线程阻塞等待 IO 线程读取 socket 完毕
4、主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行
5、主线程阻塞等待 IO 线程将数据回写 socket 完毕
6、解除绑定，清空等待队列

 该设计有如下特点：

• IO 线程要么同时在读 socket，要么同时在写，不会同时读或写

• IO 线程只负责读写 socket 解析命令，不负责命令处理

---

8、开启多线程后，是否会存在线程并发安全问题？

从上面的实现机制可以看出，Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。所以我们不需要去考虑控制 key、lua、事务，LPUSH/LPOP 等等的并发及线程安全问题。

---

9、Linux环境上如何安装Redis6.0.1（6.0的正式版是6.0.1）？

这个和安装其他版本的redis没有任何区别，整个流程跑下来也没有任何的坑，所以这里就不做描述了。唯一要注意的就是配置多线程数一定要小于cpu的核心数，查看核心数量命令：

[root@centos7.5 ~]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3

---

10、Redis作者是如何点评 “多线程”这个新特性的？

关于多线程这个特性，在6.0 RC1时，Antirez曾做过说明：

Redis支持多线程有2种可行的方式：第一种就是像“memcached”那样，一个Redis实例开启多个线程，从而提升GET/SET等简单命令中每秒可以执行的操作。这涉及到I/O、命令解析等多线程处理，因此，我们将其称之为“I/O threading”。另一种就是允许在不同的线程中执行耗时较慢的命令，以确保其它客户端不被阻塞，我们将这种线程模型称为“Slow commands threading”。

经过深思熟虑，Redis不会采用“I/O threading”，redis在运行时主要受制于网络和内存，所以提升redis性能主要是通过在多个redis实例，特别是redis集群。接下来我们主要会考虑改进两个方面：

• Redis集群的多个实例通过编排能够合理地使用本地实例的磁盘，避免同时重写AOF。

• 提供一个Redis集群代理，便于用户在没有较好的集群协议客户端时抽象出一个集群。

补充说明一下，Redis和memcached一样是一个内存系统，但不同于Memcached。多线程是复杂的，必须考虑使用简单的数据模型，执行LPUSH的线程需要服务其他执行LPOP的线程。

我真正期望的实际是“slow operations threading”，在redis6或redis7中，将提供“key-level locking”，使得线程可以完全获得对键的控制以处理缓慢的操作。

详见：An update about Redis developments in 2019 - <antirez>

---

11、Redis线程中经常提到IO多路复用，如何理解？

这是IO模型的一种，即经典的Reactor设计模式，有时也称为异步阻塞IO。

多路指的是多个socket连接，复用指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll是最新的也是目前最好的多路复用技术。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求，且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了Redis具有很高的吞吐量。

---

12、Redis多线程模型缺陷

随着互联网的飞速发展，互联网业务系统所要处理的线上流量越来越大，Redis 的单线程模式会导致系统消耗很多 CPU 时间在网络 I/O 上从而降低吞吐量，于是诞生了Redis6.0多线程模型。

但是 Redis 多线程网络模型实际上并不是一个标准的 Multi-Reactors/Master-Workers模型。Redis 的多线程方案中，I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析，却没有真正去执行命令。所有客户端命令最后还需要回到主线程去执行，因此对多核的利用率并不算高，而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。

在我看来，Redis 目前的多线程方案更像是一个折中的选择：既保持了原系统的兼容性，又能利用多核提升 I/O 性能。

---

参考链接：

Redis 6.0 新特性-多线程连环13问！ - 牧码哥 - 博客园

Redis多线程演进

Redis6.0为何引入多线程？单线程不香吗？

---

前言

Redis 官方在 2020 年 5 月份正式推出了 6.0 版本，这个版本中有很多的新特性，分别是面向网络处理的多 IO 线程、客户端缓存、细粒度的权限控制，以及 RESP 3 协议的使用。

1. 面向网络处理的多 IO 线程可以提高网络请求处理的速度；
2. 客户端缓存可以让应用直接在客户端本地读取数据，这两个特性可以提升 Redis 的性能。
3. 细粒度权限控制让 Redis 可以按照命令粒度控制不同用户的访问权限，加强了 Redis 的安全保护；
4. RESP 3 协议则增强客户端的功能，让应用更加方便地使用 Redis 的不同数据类型。

一、从单线程处理网络请求到多线程处理

在 Redis 6.0 中，非常受关注的第一个新特性就是多线程。因为 Redis 一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF 重写），但是从网络 IO 处理到实际的读写命令处理，都是由单线程完成的。

随着网络硬件的性能提升，Redis 的性能瓶颈有时会出现在网络 IO 的处理上，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。

应对这个问题有两种方法：

1. 用用户态网络协议栈（例如 DPDK）取代内核网络协议栈，让网络请求的处理不用在内核里执行，直接在用户态完成处理就行。避免频繁让内核进行网络请求处理，很好地提升请求处理效率。但是这个方法要求在 Redis 的整体架构中，添加对用户态网络协议栈的支持，需 要修改 Redis 源码中和网络相关的部分（例如修改所有的网络收发请求函数），这会带来很多开发工作量。而且新增代码还可能引入新 Bug，导致系统不稳定。所以 Redis 6.0 中 并没有采用这个方法。
2. 采用多个 IO 线程来处理网络请求，提高网络请求处理的并行度。Redis 6.0 就是采用的这种方法。但是 Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令 Redis 仍然使用单线程来处理。因为 Redis 处理请求时，网络处理经常是瓶颈，通过多个 IO 线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证 Lua 脚本、事务的原子性，额外开发多线程互斥机制了。这样 Redis 线程模型实现就简单了。

在 Redis 6.0 中，主线程和 IO 线程协作完成请求处理的原理，把主线程和多 IO 线程的协作分成四个阶段：

1. 服务端和客户端建立 Socket 连接，并分配处理线程：
   首先，主线程负责接收建立连接请求。当有客户端请求和实例建立 Socket 连接时，主线程会创建和客户端的连接，并把 Socket 放入全局等待队列中。紧接着主线程通过轮询方法 把 Socket 连接分配给 IO 线程。

2. IO 线程读取并解析请求：
   主线程一旦把 Socket 分配给 IO 线程，就会进入阻塞状态，等待 IO 线程完成客户端请求读取和解析。因为有多个 IO 线程在并行处理，所以这个过程很快就可以完成。

3. 主线程执行请求操作：
   等到 IO 线程解析完请求，主线程还是会以单线程的方式执行这些命令操作。
   

4. IO 线程回写 Socket 和主线程清空全局队列：
   当主线程执行完请求操作后，会把需要返回的结果写入缓冲区，然后主线程会阻塞等待 IO 线程把这些结果回写到 Socket 中，并返回给客户端。和 IO 线程读取和解析请求一样，IO 线程回写 Socket 时，也是有多个线程在并发执行， 所以回写 Socket 的速度也很快。等到 IO 线程回写 Socket 完毕，主线程会清空全局队列，等待客户端的后续请求。
   下图展示了这个阶段主线程和 IO 线程的操作，你可以看下。
   

在 Redis 6.0 中， 多线程机制默认是关闭的，如果需要使用多线程功能，需要在 redis.conf 中完成两个设置：

1. 设置 io-thread-do-reads 配置项为 yes，表示启用多线程：

io-threads-do-reads yes

2. 设置线程个数。一般线程个数要小于 Redis 实例所在机器的 CPU 核个数，例如，一个 8 核的机器 Redis 官方建议配置 6 个 IO 线程：

io-threads 6

如果在实际应用中，发现 Redis 实例的 CPU 开销不大，吞吐量却没有提升，可以考虑使用 Redis 6.0 的多线程机制，加速网络处理，进而提升实例的吞吐量。

二、实现服务端协助的客户端缓存

Redis 6.0 新增了一个重要的特性，实现了服务端协助的客户端缓存功能，也称为跟踪（Tracking）功能。有了这个功能，业务应用中的 Redis 客户端可以把读取的数据缓存在业务应用本地了，应用就可以直接在本地快速读取数据了。

不过当把数据缓存在客户端本地会面临一个问题：如果数据被修改了或是失效了，如何通知客户端对缓存的数据做失效处理？

6.0 实现的 Tracking 功能实现了两种模式来解决这个问题：

1. 普通模式。实例会在服务端记录客户端读取过的 key，并监测 key 是否有修改。一旦 key 的值发生变化，服务端会给客户端发送 invalidate 消息，通知客户端缓存失效了。需要注意，服务端对于记录的 key 只会报告一次 invalidate 消息，服务端在给客户端发送过一次 invalidate 消息后，如果 key 再被修改，服务端就不会再次给客户端发送 invalidate 消息。只有当客户端再次执行读命令时，服务端才会再次监测被读取的 key，并在 key 修改时发送 invalidate 消息。这样设计的考虑是节省有限的内存空间。毕竟如果客户端不再访问这个 key 了，而服务端仍然记录 key 的修改情况，就会浪费内存资源。
   通过执行下面的命令，打开或关闭普通模式下的 Tracking 功能：

CLIENT TRACKING ON|OFF

2. 广播模式。服务端会给客户端广播所有 key 的失效情况，这样做了之后，如果 key 被频繁修改，服务端会发送大量的失效广播消息，这就会消耗大量的网络带宽资源。所以在实际应用时，让客户端注册希望跟踪的 key 的前缀，当带有注册前缀的 key 被修改时，服务端会把失效消息广播给所有注册的客户端。和普通模式不同，在广播模式下，即使客户端还没有读取过 key，但只要它注册了要跟踪的 key，服务端都会把 key 失效消息通知给这个客户端。这种监测带有前缀的 key 的广播模式，需要对 key 的命名规范。在实际应用时，会给同一业务下的 key 设置相同的业务名前缀，就可以非常方便地使用 广播模式。
   例如，客户端使用广播模式接收 key 失效消息。在客户端执行下面的命令后，如果服务端更新了 user : id : 1003 这个 key，客户端就会收到 invalidate 消息。

CLIENT TRACKING ON BCAST PREFIX user

不过普通模式和广播模式，需要客户端使用 RESP 3 协议，RESP 3 协议是 6.0 新启用的通信协议。

使用 RESP 2 协议的客户端需要使用另一种模式，也就是重定向模式 （redirect）。在重定向模式下，想要获得失效消息通知的客户端，就需要执行订阅命令 SUBSCRIBE，专门订阅用于发送失效消息的频道 redis:invalidate。同时再使用另外一个客户端，执行 CLIENT TRACKING 命令，设置服务端将失效消息转发给使用 RESP 2 协议的客户端。

例如，使用 RESP 2 协议的客户端接受失效消息。假设客户端 B 想要获取失效消息，但是客户端 B 只支持 RESP 2 协议，客户端 A 支持 RESP 3 协议。可以分别在客户端 B 和 A 上执行 SUBSCRIBE 和 CLIENT TRACKING，如下所示：

//客户端B执行，客户端B的ID号是303 
SUBSCRIBE _redis_:invalidate 
//客户端A执行 
CLIENT TRACKING ON BCAST REDIRECT 303 

这样设置以后，如果有键值对被修改了，客户端 B 就可以通过 redis:invalidate 频道， 获得失效消息了。

三、从简单的基于密码访问到细粒度的权限控制

Redis 6.0 提供了实例的访问权限控制列表功能（Access Control List，ACL），提升 Redis 的使用安全性

在 Redis 6.0 版本之前，要想实现实例的安全访问，只能通过设置密码来控制，例如，客户端连接实例前需要输入密码。对于一些高风险的命令（例如 KEYS、FLUSHDB、FLUSHALL 等），在 Redis 6.0 之前，也只能通过 rename-command 来重新命名这些命令，避免客户端直接调用。

Redis 6.0 提供了更加细粒度的访问权限控制，有两方面的体现：

1. 6.0 版本支持创建不同用户来使用 Redis。在 6.0 版本前，所有客户端可以使用同一个密码进行登录使用，但是没有用户的概念，而在 6.0 中，可以使用 ACL SETUSER 命令创建用户。执行下面的命令，创建并启用一个用户 normaluser，把它的密码设置为“abc”：

ACL SETUSER normaluser on > abc

2. 6.0 版本还支持以用户为粒度设置命令操作的访问权限。具体操作在下表中，加号（+）和减号（-）就分别表示给用户赋予或撤销命令的调用权限。

假设要设置用户 normaluser 只能调用 Hash 类型的命令操作，而不能调用 String 类型的命令操作，执行如下命令：

ACL SETUSER normaluser +@hash -@string

6.0 版本还支持以 key 为粒度设置访问权限，使用波浪号“~”和 key 的前缀来表示控制访问的 key。执行下面命令，设置用户 normaluser 只能对以“user:”为前缀的 key 进行命令操作：

ACL SETUSER normaluser ~user:* +@all

Redis 6.0 可以设置不同用户来访问实例，而且可以基于用户和 key 的粒度，设置某个用户对某些 key 允许或禁止执行的命令操作。在有多用户的 Redis 应用场景下，非常方便和灵活地为不同用户设置不同级别的命令操作权限，这对于提供安全的 Redis 访问非常有帮助。

四、启用 RESP 3 协议

Redis 6.0 实现了 RESP 3 通信协议，之前都是使用的 RESP 2。在 RESP 2 中，客户端和服务器端的通信内容都是以字节数组形式进行编码的，客户端需要根据操作的命令或是数据类型自行对传输的数据进行解码，增加了客户端开发复杂度。

RESP 3 直接支持多种数据类型的区分编码，包括空值、浮点数、布尔值、有序的字典集合、无序的集合等。

区分编码指直接通过不同的开头字符，区分不同的数据类型，这样客户端就可以直接通过判断传递消息的开头字符，来实现数据转换操作了，提升了客户端的效率。除此之外，RESP 3 协议还可以支持客户端以普通模式和广播模式实现客户端缓存。

总结

Redis 6.0 的新特性：

Redis 6.0 新的功能特性需要在实际应用中进行部署和验证，所以如果想试用 Redis 6.0，可以尝试先在非核心业务上使用 Redis 6.0，一方面可以验证新特性带来的性能或功能优势，另一方面，也可以避免因为新特性不稳定而导致核心业务受到影响。

---

前言

本文参考源码版本为 redis6.2

一般来说，一个 redis 请求有两大模块，网络模块 + 命令处理模块。我们常说的 redis 单线程模型，其实主要就指的是一个正常请求涉及的网络模块和命令处理模块。

当执行一个特别慢的命令时，比如删除一个百万级的字典，可能会造成暂时的卡顿，导致 QPS 骤降；基于此，在 redis 4.0 出现专门处理这种 Lazy Free 模型的后台线程。

另外，正常情况下，redis 单线程模型中，网络模块往往成为瓶颈高发地；因此，redis 6.0 引入多线程模型，解决网络模块的问题。

前面系列文章已经介绍了 redis 的单线程模型及其背后的后台线程，因此，本文主要焦点集中在 redis 6.0 出现的多线程。

在开始阅读之前，你也可以思考一个问题：命令处理为什么不采用多线程模型？

---

一、架构演进？

复杂架构都是逐渐演进而来，从单线程到多线程，从单体功能到复杂功能等等，redis 也是如此。

redis 单线程情况下，也能达到极高的吞吐量，但某些情况下，会出现相当耗时的操作，导致吞处理骤降，因此逐渐引入后台线程来完成这些操作。

慢慢地，当我们要求更高的吞吐量时，网络模块却经常掉链子，在 redis 6.0 中又引入多线程来解决这个问题 ----- 这也是本文主要探讨的问题。

话不多说，开始吧～

1. 单线程

redis 是单线程模式 ------- 这是我们经常听到了说法，仅靠一个线程就能达到几万QPS，简直令人称奇！

我画了张单线程模型图，大概是这样：

你可以直观的看到，redis 确实仅靠一个线程处理了所有客户端的请求，一条龙服务！！！

从接收新连接、IO就绪监听、IO读，到命令执行，最后到命令执行后的数据回复（IO写）等都是一个线程处理，这些操作的封装，redis 中称之为文件事件；

当然，还有。redis 中的另一大事件 ------- 时间事件，负责相关的周期性处理任务，比如 key 过期清理、字典 rehash、触发 AOF 重写/RDB 的 bgsave等等。

值得注意的是，文件事件 和 时间事件 都是由主线程来驱动完成的。入口是 aeMain() 方法，redis 服务启动后，将会一直在此方法中轮训监听事件。

到这，你可能会说，一个线程做这么多事还不得累死？

是的，一个线程串行做这么多事情确实存在很大风险，对于一些耗时长的操作，可能严重拖垮 redis 吞吐量，所以，redis 又搞了一些后台线程来专门处理这些耗时操作。

2. 单线程+后台线程

特别需要注意的是！！！我们经常听说的 redis 单线程模型（上图），其实仅仅指的是对客户端的请求处理，但其实，还有一些工作由对应特殊的线程来完成。

在 redis 6.0 以前，完整的 redis 线程模型是 主线程（1个）+ 后台线程（三个），我画了一张图，你可以看下：
三个后台线程分别处理：

• close_file：关闭 AOF、RDB 等过程中产生的大临时文件
• aof_fsync：将追加至 AOF 文件的数据刷盘（一般情况下 write 调用之后，数据被写入内核缓冲区，通过 fsync 调用才将内核缓冲区的数据写入磁盘）
• lazy_free：惰性释放大对象

这三个线程有一个共同特点，都是用来处理耗时长的操作，也印证了我们常说的，专业的人做专业的事。

3. 多线程+后台线程

咱们继续将时钟往后拨到 redis6.0 版本，此版本出现了一种新的 IO 线程 ---- 多线程。我同样也画了张图，你可以看下：

我们先思考下，引进 IO 线程解决了哪些问题？

在之前系列文章中，我们提到过，通常情况下，redis 性能在于网络和内存，而不是 CPU。针对 网络，一般是处理速度较慢的问题；针对内存，一般是指物理空间的限制。

所以到这，你应该很清楚了，究竟哪个模块需要引入多线程来处理？

没错，就是网络模块，因此，引入的这些线程也叫 IO线程；由于主线程也会处理网络模块的工作，因此，主线程习惯上也叫做主IO线程。

网络模块有接收连接、IO读（包括数据解析）、IO写等操作；其中，主线程负责接收新连接，然后分发到 IO线程进行处理（主线程也参与）。我画了张图，你可以看下：

默认情况下，只针对写操作启用IO线程，如果读操作也需要的话，需要在配置文件中进行配置：

// server.c#redisServer结构体
int io_threads_do_reads;

二、原理

前面我们已经讲到，redis 6.0 出现的多线程主要致力于解决网络模块的瓶颈，通过使用多线程处理读/写客户端数据，进而分担主IO线程的压力。

值得注意的是，命令处理仍然是单线程执行。

为了更好的帮助你理解，我们再来回顾下，请求处理流程：

接下来，我们将结合源码，看看多线程如何大展身手～

1. 初始化

在 server.c#main 启动的最后阶段，调用方法 InitServerLast，我们来看看其实现：

// server.c#InitServerLast
void InitServerLast() {
    bioInit();
    initThreadedIO();
    set_jemalloc_bg_thread(server.jemalloc_bg_thread);
    server.initial_memory_usage = zmalloc_used_memory();
}

其中，initThreadedIO 调用正是初始化 IO 线程：

// networking.c#initThreadedIO
void initThreadedIO(void) {
    server.io_threads_active = 0; /* We start with threads not active. */

    /* Don't spawn any thread if the user selected a single thread:
     * we'll handle I/O directly from the main thread. */
    if (server.io_threads_num == 1) return;

    if (server.io_threads_num > IO_THREADS_MAX_NUM) {
        serverLog(LL_WARNING,"Fatal: too many I/O threads configured. "
                             "The maximum number is %d.", IO_THREADS_MAX_NUM);
        exit(1);
    }

    /* Spawn and initialize the I/O threads. */
    for (int i = 0; i < server.io_threads_num; i++) {
        /* Things we do for all the threads including the main thread. */
        io_threads_list[i] = listCreate();
        if (i == 0) continue; /* Thread 0 is the main thread. */

        /* Things we do only for the additional threads. */
        pthread_t tid;
        pthread_mutex_init(&io_threads_mutex[i],NULL);
        setIOPendingCount(i, 0);
        pthread_mutex_lock(&io_threads_mutex[i]); /* Thread will be stopped. */
        // 真正的创建线程，并指定处理方法 IOThreadMain
        if (pthread_create(&tid,NULL,IOThreadMain,(void*)(long)i) != 0) {
            serverLog(LL_WARNING,"Fatal: Can't initialize IO thread.");
            exit(1);
        }
        io_threads[i] = tid;
    }
}

值得注意的是，i == 0 表示主IO线程！！！

我们定位到 for 循环中的 pthread_create 方法 ---- 真正的创建线程的方法，并指定线程的执行方法体 IOThreadMain — 主角。

void *IOThreadMain(void *myid) {
    /* The ID is the thread number (from 0 to server.iothreads_num-1) */
    long id = (unsigned long)myid;
    char thdname[16];

    snprintf(thdname, sizeof(thdname), "io_thd_%ld", id);
    redis_set_thread_title(thdname);
    redisSetCpuAffinity(server.server_cpulist);
    makeThreadKillable();

    while(1) {
        /* Wait for start */
        for (int j = 0; j < 1000000; j++) {
            if (getIOPendingCount(id) != 0) break;
        }

        /* Give the main thread a chance to stop this thread. */
        if (getIOPendingCount(id) == 0) {
            pthread_mutex_lock(&io_threads_mutex[id]);
            pthread_mutex_unlock(&io_threads_mutex[id]);
            continue;
        }

        serverAssert(getIOPendingCount(id) != 0);

        if (tio_debug) printf("[%ld] %d to handle\n", id, (int)listLength(io_threads_list[id]));

        /* Process: note that the main thread will never touch our list
         * before we drop the pending count to 0. */
        listIter li;
        listNode *ln;
        listRewind(io_threads_list[id],&li);
        while((ln = listNext(&li))) {
            client *c = listNodeValue(ln);
            if (io_threads_op == IO_THREADS_OP_WRITE) {
                writeToClient(c,0);
            } else if (io_threads_op == IO_THREADS_OP_READ) {
                readQueryFromClient(c->conn);
            } else {
                serverPanic("io_threads_op value is unknown");
            }
        }
        listEmpty(io_threads_list[id]);
        setIOPendingCount(id, 0);

        if (tio_debug) printf("[%ld] Done\n", id);
    }
}

如果你熟悉 java 的话，应该知道 IOThreadMain 就相当于 runable 的具体实现。核心逻辑在于 while(1) 无限循环中。

从源码中看到，IO 线程是从 io_threads_list 队列（或者说列表）获取待处理的客户端，并根据操作类型选择具体的执行逻辑。

看到这，你应该就豁然开朗了，这就是典型的 生产者-消费者模型，主IO线程负责投递事件，IO 线程负责消费事件（主线程也参与）。

从 IO 线程执行主体中，我们看到，通过 writeToClient 处理写请求， readQueryFromClient 处理读请求，我们接下来将具体分析这两种情况～

2. 多线程读

一般情况下，当我们通过多路复用监听到客户端数据准备就绪时，将会在主事件循环中，轮询处理这批就绪的客户端。

从读取数据 => 数据解析 => 命令执行 => 写会客户端缓冲区 => 待下一轮主事件循环到来时，将客户端缓冲数据写会客户端。

在多线程模式下（假设配置了多线程读），上述流程有了些许变化：读取数据 => 数据解析 模块处理操作，将均分给多个 IO 线程处理（包括主IO线程）。

所有就绪客户端暂存至队列：

struct redisServer {  
   ...
   
   list *clients_pending_read;
   
   ...
} 

1）入队：

具体代码上的体现是，postponeClientRead 返回 1 之后，将直接退出。

// networking.c#readQueryFromClient
void readQueryFromClient(connection *conn) {
    client *c = connGetPrivateData(conn);
    int nread, readlen;
    size_t qblen;

    // 如果 IO 线程读开启，退出操作，待下一次 eventloop 循环到来时处理
    if (postponeClientRead(c)) return;

    ...
    
}

多线程读开启时，函数 postponeClientRead 是关键：

// networking.c#postponeClientRead
int postponeClientRead(client *c) {
    if (server.io_threads_active &&
        server.io_threads_do_reads &&
        !ProcessingEventsWhileBlocked &&
        !(c->flags & (CLIENT_MASTER|CLIENT_SLAVE|CLIENT_PENDING_READ)))
    {
        c->flags |= CLIENT_PENDING_READ;
        listAddNodeHead(server.clients_pending_read,c);
        return 1;
    } else {
        return 0;
    }
}

可以看到，当我们开启 读 IO 多线程配置，将直接将该客户端添加至队列中，等待进行分配（下一轮 eventloop 循环）。

2）分配：

在新一轮 eventloop 循环，通过 IO 多路复用查询之前（这一步通常是阻塞等待，因此，也常称为阻塞操作），会调用 beforeSleep 处理一些客户端的操作，其中就包括多线程读取客户端数据，刷新客户端缓存数据至客户端。

来看看 handleClientsWithPendingReadsUsingThreads 方法：

// networking.c#handleClientsWithPendingReadsUsingThreads
int handleClientsWithPendingReadsUsingThreads(void) {
    // 如果没有开启多线程IO读，将直接退出
    if (!server.io_threads_active || !server.io_threads_do_reads) return 0;
    
    ...
    
    // 将客户端均分，每个IO线程有对应的队列
    listRewind(server.clients_pending_read,&li);
    int item_id = 0;
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        int target_id = item_id % server.io_threads_num;
        listAddNodeTail(io_threads_list[target_id],c);
        item_id++;
    }

    // 通知等待的IO线程
    io_threads_op = IO_THREADS_OP_READ;
    for (int j = 1; j < server.io_threads_num; j++) {
        int count = listLength(io_threads_list[j]);
        setIOPendingCount(j, count);
    }

    // 主线程也要参与处理部分客户端
    listRewind(io_threads_list[0],&li);
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        readQueryFromClient(c->conn);
    }
    listEmpty(io_threads_list[0]);

    // 等待所有线程完成操作
    while(1) {
        unsigned long pending = 0;
        for (int j = 1; j < server.io_threads_num; j++)
            pending += getIOPendingCount(j);
        if (pending == 0) break;
    }
    if (tio_debug) printf("I/O READ All threads finshed\n");

    ...

    return processed;
}

主要处理：

• 将待处理客户端（clients_pending_read）均分至各 IO 线程对应队列中（主IO线程参与均分）
• 通知等待中的 IO 线程
• 主IO线程处理部分客户端
• 等待所有 IO 线程处理结束

简单总结以上两点：

• 当多线程读开启，并且多线程处于激活状态，客户端暂存于队列；反之直接通过 readQueryFromClient 进行处理。
• 暂存于队列中的客户端，会在下一次 eventloop 中，before sleep 之前，分发至IO线程各自的队列中处理

再次强调，主IO线程也参与处理。

3. 多线程写：

同样的，客户端响应数据也是先写到队列：

struct redisServer {  
   ...
   
   list *clients_pending_write;
   
   ...
} 

从处理时机上看，多线程 写与读 都是在 beforeSleep 中被触发的，写操作是通过 handleClientsWithPendingWritesUsingThreads 完成：

// networking.c#handleClientsWithPendingWritesUsingThreads
int handleClientsWithPendingWritesUsingThreads(void) {
    int processed = listLength(server.clients_pending_write);
    if (processed == 0) return 0; /* Return ASAP if there are no clients. */

    // 如果没有启用多线程写，或者仅有少量客户端，写操作就直接由主IO线程来完成。
    if (server.io_threads_num == 1 || stopThreadedIOIfNeeded()) {
        return handleClientsWithPendingWrites();
    }

    // 激活IO线程
    if (!server.io_threads_active) startThreadedIO();

    ...

    // 分发客户端至IO线程的队列中
    listRewind(server.clients_pending_write,&li);
    int item_id = 0;
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        c->flags &= ~CLIENT_PENDING_WRITE;

        // 如果客户端已关闭，直接移除即可
        if (c->flags & CLIENT_CLOSE_ASAP) {
            listDelNode(server.clients_pending_write, ln);
            continue;
        }

        int target_id = item_id % server.io_threads_num;
        listAddNodeTail(io_threads_list[target_id],c);
        item_id++;
    }

    // 通知等待中的线程
    io_threads_op = IO_THREADS_OP_WRITE;
    for (int j = 1; j < server.io_threads_num; j++) {
        int count = listLength(io_threads_list[j]);
        setIOPendingCount(j, count);
    }

    // 主线程也要处理部分客户端
    listRewind(io_threads_list[0],&li);
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        writeToClient(c,0);
    }
    listEmpty(io_threads_list[0]);

    // 等待所有线程完成工作
    while(1) {
        unsigned long pending = 0;
        for (int j = 1; j < server.io_threads_num; j++)
            pending += getIOPendingCount(j);
        if (pending == 0) break;
    }
    
    ...
    
    return processed;
}

该方法主要做了几件事情：

• 如果没有启用多线程写，或者仅有少量客户端，写操作就直接由主IO线程来完成。
• 激活IO线程（当待客户端较少时，会挂起IO线程 ---- 锁等待）
• 通知等待中的线程（共享变量值 > 0 时，表示有待处理任务）
• 主线程也要处理部分客户端。
• 等待所有线程完成工作。

值得注意的是，当 待处理客户端 过少时，redis 认为没必要采用多线程来共同处理，因此，完全交给主IO线程来完成：

int stopThreadedIOIfNeeded(void) {
    int pending = listLength(server.clients_pending_write);

    if (server.io_threads_num == 1) return 1;

    if (pending < (server.io_threads_num*2)) {
        if (server.io_threads_active) stopThreadedIO();
        return 1;
    } else {
        return 0;
    }
}

可见，当 待处理客户端 < 2倍IO线程数 时，将由主 IO 线程完成所有客户端数据刷回。

三、配置

redis 默认情况下不会开启多线程处理，官方也建议，除非性能达到瓶颈，否则没必要开启多线程。

配置多少合适？

官方文档 redis.conf 中介绍有：

By default threading is disabled, we suggest enabling it only in machines
that have at least 4 or more cores, leaving at least one spare core.
Using more than 8 threads is unlikely to help much. We also recommend using
threaded I/O only if you actually have performance problems, with Redis
instances being able to use a quite big percentage of CPU time, otherwise
there is no point in using this feature.

So for instance if you have a four cores boxes, try to use 2 or 3 I/O
threads, if you have a 8 cores, try to use 6 threads. In order to
enable I/O threads use the following configuration directive:

CPU 4 核以上，才考虑开启多线程，其中：

• 4 核开启 2 - 3 个 IO 线程
• 8 核 开启 6 个 IO 线程
• 超过 8 个 IO 线程，性能提升已经不大

值得注意的是，以上的 IO 线程其实包含了主 IO 线程。

配置：

开启多线程：配置 io-thread 即可。io-thread = 1 表示只使用主 IO 线程

io-threads 4

开启之后，默认写操作会通过多线程来处理，而读操作则不会。

如果读操作也想要开启多线程，则需要配置：

io-threads-do-reads yes

---

总结

本文从 redis 架构演进开始讲起，从单线程模型 => 单线程 + 后台线程 => 多线程 + 后台线程 演进。

每一次演进，都是为了解决某一类特殊问题；后台线程的出现，解决了一些耗时长的重操作。同样，多线程的出现，解决了网络模块的性能瓶颈。

回到开篇问题：为什么命令执行为什么不采用多线程？

• 使用多线程会提升复杂度，对于 redis 这种内存数据库，代价太高
• 一般情况下，redis 的瓶颈在于网络模块和内存，而非 CPU
• 可以在一台机器上部署多个实例（集群模式）
• 复杂（慢）命令可以通过 redis module 解决

相关文档：

• An update about Redis developments in 2019 - Antirez
• How can Redis use multiple CPUs or cores?
• Redis事件驱动框架（下），时间事件&文件事件详解
• 一文搞懂，redis单线程执行全貌
• Redis 6.0之前真的是单个线程吗？（后台线程那些事）