1 单线程模型设计
我们通常说Redis是单线程，主要指Redis的网络I/O和KV对读写是由一个线程完成，是Redis对外提供KV存储服务的主要流程。 但Redis其它功能如持久化、异步删除、集群数据同步等，是由额外线程执行的。
所以，严格来说，Redis并不是单线程，但一般把Redis称为单线程高性能，显得像 UC 编辑部。所以都说Redis是单线程模式。
为何单线程模型
要弄明白这个问题，需研究Redis的单线程设计机制以及多路复用机制。 调优Redis性能时，也能针对性避免会导致Redis单线程阻塞的操作，例如执行复杂度高命令。
多线程的开销
“使用多线程，可增加系统吞吐率或增加系统扩展性”。 一个多线程系统，在合理资源分配时，可增加系统中处理请求操作的资源实体，进而提升系统能够同时处理的请求数，即吞吐率。 左图是我们采用多线程时所期待的结果。
但通常情况用多线程后，若无良好系统设计，实际得到的结果，其实是右图那样。为什么会这样？‘ 核心瓶颈在于，系统通常会存在被多线程同时访问的共享资源，如一个共享的数据结构。当多线程修改共享资源时，为保证共享资源正确性，就需额外机制保证，就直接带来额外开销。 比如Redis有List数据类型，并提供出队（LPOP）和入队（LPUSH）操作。假设Redis采用多线程设计，现有两个线程A、B：A对一个List做LPUSH操作，并对队列长度加1同时，线程B对该List执行LPOP操作，并对队列长度减1
为保证队列长度正确性，Redis要让线程A和B的LPUSH和LPOP串行执行，这样Redis可无误地记录它们对List长度修改。否则，可能得到错误结果。 这就是多线程编程面临的共享资源的并发访问控制问题。
如果无精心设计，比如只是简单采用一个粗粒度的互斥锁，就会出现不理想结果：即使增加了线程，大部分线程也在等待获取访问共享资源的互斥锁，并行变串行，系统吞吐率并没有随着线程的增加而增加。 也会引入同步原语保护共享资源的并发访问，降低系统代码的易调试性和可维护性。
为避免这些Redis直接单线程模式。
讲到这里，你应该已经明白了“Redis为什么用单线程”，那么，接下来，我们就来看看，为什么单线程Redis能获得高性能。
- 纯内存操作
- 基于非阻塞的IO多路复用机制
- 避免了多线程的频繁上下文切换
2 文件事件处理器
Redis 基于 Reactor 模式开发了自己的网络事件处理器 - 文件事件处理器（file event handler，后文简称为 FEH），而该处理器又是单线程的，所以redis设计为单线程模型。
- 采用I/O多路复用同时监听多个socket，根据socket当前执行的事件来为 socket 选择对应的事件处理器。
- 当被监听的socket准备好执行
accept、read、write、close等操作时，和操作对应的文件事件就会产生，这时FEH就会调用socket之前关联好的事件处理器来处理对应事件。
所以虽然FEH是单线程运行，但通过I/O多路复用监听多个socket，不仅实现高性能的网络通信模型，又能和 Redis 服务器中其它同样单线程运行的模块交互，保证了Redis内部单线程模型的简洁设计。
- 下面讲讲文件事件处理器的几个组成部分。
2.1 socket
文件事件就是对socket操作的抽象， 每当一个 socket 准备好执行连接accept、read、write、close等操作时， 就会产生一个文件事件。 一个服务器通常会连接多个socket， 多个socket可能并发产生不同操作，每个操作对应不同文件事件。
2.2 I/O多路复用程序
I/O 多路复用程序会负责监听多个socket。
尽管文件事件可能并发出现， 但 I/O 多路复用程序会将所有产生事件的socket放入队列， 通过该队列以有序、同步且每次一个socket的方式向文件事件分派器传送socket。 当上一个socket产生的事件被对应事件处理器执行完后， I/O 多路复用程序才会向文件事件分派器传送下个socket， 如下：
I/O多路复用程序的实现
Redis 的 I/O 多路复用程序的所有功能都是通过包装常见的 select 、 epoll 、 evport 和 kqueue 这些 I/O 多路复用函数库实现的。 每个 I/O 多路复用函数库在 Redis 源码中都对应一个单独的文件：
因为 Redis 为每个 I/O 多路复用函数库都实现了相同的 API ， 所以 I/O 多路复用程序的底层实现是可以互换的。Redis 在 I/O 多路复用程序的实现源码ae.c文件中宏定义了相应规则，使得程序在编译时自动选择系统中性能最高的 I/O 多路复用函数库作为 Redis 的 I/O 多路复用程序的底层实现：性能降序排列。
2.3 文件事件分派器
文件事件分派器接收 I/O 多路复用程序传来的socket， 并根据socket产生的事件类型， 调用相应的事件处理器。
2.4 文件事件处理器
服务器会为执行不同任务的套接字关联不同的事件处理器， 这些处理器是一个个函数， 它们定义了某个事件发生时， 服务器应该执行的动作。
处理器映射
Redis 为各种文件事件需求编写了多个处理器，若客户端：
- 连接Redis，对连接服务器的各个客户端进行应答，就需要将socket映射到连接应答处理器
- 写数据到Redis，接收客户端传来的命令请求，就需要映射到命令请求处理器
- 从Redis读数据，向客户端返回命令的执行结果，就需要映射到命令回复处理器
当主服务器和从服务器进行复制操作时， 主从服务器都需要映射到特别为复制功能编写的复制处理器。
2.5 文件事件的类型
I/O 多路复用程序可以监听多个socket的 ae.h/AE_READABLE 事件和 ae.h/AE_WRITABLE 事件， 这两类事件和套接字操作之间的对应关系如下：
- 当socket可读（比如客户端对Redis执行
write/close操作），或有新的可应答的socket出现时（即客户端对Redis执行connect操作），socket就会产生一个AE_READABLE事件
- 当socket可写时（比如客户端对Redis执行read操作），socket会产生一个AE_WRITABLE事件。
I/O多路复用程序可以同时监听AE_REABLE和AE_WRITABLE两种事件，要是一个socket同时产生这两种事件，那么文件事件分派器优先处理AE_REABLE事件。即一个socket又可读又可写时， Redis服务器先读后写socket。
3 总结
最后，让我们梳理一下客户端和Redis服务器通信的整个过程：
- Redis启动初始化时，将连接应答处理器跟AE_READABLE事件关联。
- 若一个客户端发起连接，会产生一个
AE_READABLE事件，然后由连接应答处理器负责和客户端建立连接，创建客户端对应的socket，同时将这个socket的AE_READABLE事件和命令请求处理器关联，使得客户端可以向主服务器发送命令请求。 - 当客户端向Redis发请求时（不管读还是写请求），客户端socket都会产生一个
AE_READABLE事件，触发命令请求处理器。处理器读取客户端的命令内容， 然后传给相关程序执行。 - 当Redis服务器准备好给客户端的响应数据后，会将socket的
AE_WRITABLE事件和命令回复处理器关联，当客户端准备好读取响应数据时，会在socket产生一个AE_WRITABLE事件，由对应命令回复处理器处理，即将准备好的响应数据写入socket，供客户端读取。 - 命令回复处理器全部写完到 socket 后，就会删除该socket的
AE_WRITABLE事件和命令回复处理器的映射。
参考
- 《Redis 设计与实现》
