今天，咱们就详细的聊下 I/O 多线程模型带来的效果到底是黛玉骑鬼火，该强强，该弱弱；还是犹如光明顶身怀绝技的的张无忌，招招都是必杀技。
谢霸哥：“码哥， Redis 6.0 之前单线程指的是 Redis 只有一个线程干活么？”
非也，我们通常说的单线程模型指的是 Redis 在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理。
而其他的清理过期键值对数据、释放无用连接、内存淘汰策略执行、BGSAVE 生成 RDB 内存快照文件、AOF rewrite 等都是其他线程处理。
命令执行阶段，每一条命令并不会立马被执行，而是进入一个一个 socket 队列，当 socket 事件就绪则交给事件分发器分发到对应的事件处理器处理，单线程模型的命令处理如下图所示。
图片
谢霸哥：“为什么 Redis6.0 之前是单线程模型？”
以下是官方关于为什么 6.0 之前一直使用单线程模型的回答。
Redis 的性能瓶颈主要在于内存和网络 I/O，CPU 不会是性能瓶颈所在。
Redis 通过使用 pipelining 每秒可以处理 100 万个请求，应用程序的所时候用的大多数命令时间复杂度主要使用 O(N) 或 O(log(N)) 的，它几乎不会占用太多 CPU。
单线程模型的代码可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。
Redis 通过基于 I/O 多路复用实现的 AE 事件驱动框架将 I/O 事件和事件事件融合在一起，实现高性能网络处理能力，再加上基于内存的数据处理，没有引入多线程的必要。
而且单线程机制让 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等线程不安全的命令都可以无锁进行。
谢霸哥：“既然单线程这么好，为什么 6.0 版本引入多线程模型？”
因为随着底层网络硬件性能提升，Redis 的性能瓶颈逐渐体现在网络 I/O 的读写上，单个线程处理网络读写的速度跟不上底层网络硬件执行的速度。
因为读写网络的 read/write 系统调用占用了 Redis 执行期间大部分 CPU 时间。所以 Redis 采用多个 I/O 线程来处理网络请求，提高网络请求处理的并行度。
需要注意的是，Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写命令，依然是单线程处理。
这是因为，网络 I/O 读写是瓶颈，可通过多线程并行处理可提高性能。而继续使用单线程执行读写命令，不需要为了保证 Lua 脚本、事务、等开发多线程安全机制，实现更简单。
谢霸哥：“码哥，你真是斑马的脑袋，说的头头是道。”
我谢谢您嘞，主线程与 I/O 多线程共同协作处理命令的架构图如下所示。
图片
谢霸哥：“如何开启多线程呢？”
Redis 6.0 的多线程默认是禁用的，如需开启需要修改 redis.conf 配置文件的配置io-threads-do-reads yes。
开启多线程后，还要设置线程数才能生效，同样是修改 redis.conf配置文件。
io-threads 4
谢霸哥：“码老师，线程数是不是越多越好？”
当然不是，关于线程数的设置，官方有一个建议：线程数的数量最好小于 CPU 核心数，起码预留一个空闲核处理，因为 Redis 是主线程处理指令，如果系统出现频繁上下文切换，效率会降低。
比如 4 核的机器建议设置为 2 或 3 个线程，8 核的机器建议设置为 6 个线程，线程数一定要小于机器核数。
谢霸哥：“码老师真厉害，就好像卖盆的进村一套一套的。我什么时候也能像你这样连贯又有逻辑的掌握 Redis。”
认真读 Redis 高手心法，长线放风筝慢慢来。
谢霸哥：“主线程与 I/O 线程是如何实现协作呢？”
图片
主要流程。
主线程负责接收建立连接请求，通过轮询将可读 socket 分配给 I/O 线程绑定的等待队列。
主线程阻塞等待，直到 I/O 线程完成 socket 读取和解析。
主线程执行 I/O 线程读取和解析出来的 Redis 请求命令。
主线程阻塞等待 I/O 线程将指令执行结果回写回 socket完毕。
主线程清空等待队列，等待下一次客户端后续的请求。
思路：将主线程 IO 读写任务拆分出来给一组独立的线程处理，使得多个 socket 读写可以并行化，但是 Redis 命令还是主线程串行执行。
大家注意第三和第五步，主线程并不是挂起线程让出 CPU 分片时间。而是通过 for 循环进行忙等，不断的检测所有 I/O 线程处理任务是否已经完成，完成再执行下一步。
看完流程图以及主要步骤，接着跟着源码走一个。通过 4.3 章节的学习，我们知道 Redis 是通过 server.c的main函数启动的，经过一系列的初始化操作后，调用 aeMain(server.el);启动事件驱动框架，也就是整个 Redis 的核心。
I/O 多线程模型的开端也是由 server.c的main方法中的 InitServerLast来初始化，该方法内部会调用 networking.c 的 initThreadedIO来执行实际 I/O 线程初始化工作。
/* networking.c */void initThreadedIO(void){// 设置成 0 表示激活 I/O 多线程模型server.io_threads_active=0;/* I/O 线程处于空闲状态 */io_threads_op=IO_THREADS_OP_IDLE;/* 如果 redis.conf 的 io-threads 配置为 1 表示使用单线程模型，直接退出 */if(server.io_threads_num==1)return;// 线程数超过最大值 128，退出程序if(server.io_threads_num>IO_THREADS_MAX_NUM){....省略exit(1);}for(inti=0;i<server.io_threads_num;i++){/* io_threads_list 链表，用于存储该线程要执行的 I/O 操作。*/io_threads_list[i]=listCreate();// 0 号线程不创建，0 号就是主线程，主线程也会处理任务逻辑。if(i==0)continue;// 创建线程，主线程先对子线程上锁，挂起子线程，不让其进入工作模式pthread_t tid;pthread_mutex_init(&io_threads_mutex[i],NULL);setIOPendingCount(i,0);// 挂起子线程，先不进入工作模式，等待主线程发出干活信号再执行任务。pthread_mutex_lock(&io_threads_mutex[i]);// 创建线程，指定I/O线程的入口函数 IOThreadMainif(pthread_create(&tid,NULL,IOThreadMain,(void*)(long)i)!=0){
serverLog(LL_WARNING,"Fatal: Can't initialize IO thread.");exit(1);}// I/O 线程数组io_threads[i]=tid;}
}
检查是否开启 I/O 多线程模型：默认不激活 I/O 多线程模型，当 redis.conf 的 io-threads 配置大于 1 并且小于 IO_THREADS_MAX_NUM（128） 则表示开启 I/O 多线程模式。
创建 io_threads_list 链表，用于保存每个线程需要处理的 I/O 任务。
创建子线程，创建的时候先上锁，挂起子线程不让其进入工作模式，等初始化工作完成再开启。
指定 I/O 线程的入口函数 IOThreadMain，I/O 线程开始工作。
IOThreadMain 函数主要负责等待启动信号、执行特定的 I/O 操作，并在完成操作后重置线程状态，以便再次等待下一次启动信号。
void*IOThreadMain(void*myid){/* 每个线程创建一个 id */long id=(unsignedlong)myid;charthdname[16];.....// 进入无限循环，等待主线程发出干活信号while(1){/* 没有使用 sleep 设置等待时间实现忙等，而是循环，耗费 CPU*/for(intj=0;j<1000000;j++){// 等待待处理的 I/O 操作出现，也就是读写客户端数据if(getIOPendingCount(id)!=0)break;}/*留机会给主线程上锁，挂起当前子线程 */if(getIOPendingCount(id)==0){
pthread_mutex_lock(&io_threads_mutex[id]);pthread_mutex_unlock(&io_threads_mutex[id]);continue;}
serverAssert(getIOPendingCount(id)!=0);/* 根据线程 id 以及待分配列表进行任务分配 */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);}elseif(io_threads_op==IO_THREADS_OP_READ){// 读取客户端 socket 数据readQueryFromClient(c->conn);}else{
serverPanic("io_threads_op value is unknown");}
}
listEmpty(io_threads_list[id]);setIOPendingCount(id,0);}
}
Redis 会在主线程 initServer 初始化服务器的时候会注册 beforeSleep函数，里面会调用 handleClientsWithPendingReadsUsingThreads函数实现待处理任务分配逻辑。该函数的主要作用如下。
将所有待读的客户端平均分配到不同的 I/O 线程的列表中。
通过设置 io_threads_op 和调用 setIOPendingCount 函数，通知各个 I/O 线程开始处理可读取的客户端数据。
主线程也参与处理客户端读取，以确保更好的并发性能。
主线程等待所有 I/O 线程完成读取 socket 工作。
这种设计采用了“扇出 -> 扇入”的范式，通过将工作分发到多个 I/O 线程，再将结果合并回主线程，以提高并发性能。
inthandleClientsWithPendingReadsUsingThreads(void){....../* 将所有待处理的客户端平均分配到不同的 I/O 线程的列表中*/listIter li;listNode*ln;listRewind(server.clients_pending_read,&li);intitem_id=0;while((ln=listNext(&li))){
client*c=listNodeValue(ln);inttarget_id=item_id%server.io_threads_num;listAddNodeTail(io_threads_list[target_id],c);item_id++;}/* 通过设置 `io_threads_op` 和调用 `setIOPendingCount` 函数，通知各个 I/O 线程开始处理可读取的客户端数据。 */io_threads_op=IO_THREADS_OP_READ;for(intj=1;j<server.io_threads_num;j++){intcount=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]);/* 主线程处理完任务后，忙等等待所有 I/O 线程完成读取 socket 工作 */while(1){unsignedlong pending=0;for(intj=1;j<server.io_threads_num;j++)pending+=getIOPendingCount(j);if(pending==0)break;}......returnprocessed;}
与上面类似， beforeSleep函数里面会调用 handleClientsWithPendingWritesUsingThreads函数实现可写客户端处理任务分配给 I/O 线程，源代码跟 handleClientsWithPendingReadsUsingThreads类似，不贴了。差别就是这个函数处理的事情是把响应写回 socket。
将所有待写的客户端平均分配到不同的 I/O 线程的列表中。
设置 io_threads_op 为 IO_THREADS_OP_READ通知各个 I/O 线程开始处理可写的客户端数据。
主线程也参与处理客户端读取，以确保更好的并发性能。
主线程等待所有 I/O 线程完成读取 socket 工作。
Redis 的多线程网络模型实际上并不是一个标准的 Multi-Reactors/Master-Workers 模型，I/O 线程任务仅仅是通过 socket 读取客户端请求命令并解析，以及把指令执行结果回写给 socket ，没有真正去执行命令。
所有客户端命令最后还需要回到主线程去执行，因此对多核的利用率并不算高，而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。
在我看来，Redis 目前的多线程方案更像是一个折中的选择，只是黛玉骑鬼火，还未达到必杀技的阶段。