Redis 的单线程模型

参考：http://www.javashuo.com/article/p-otjatuie-de.html

 

Redis 内部使用文件事件处理器 file event handler ，这个文件事件处理器是单线程的，因此 Redis 才叫作单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，将产生事件的 socket 压入内存队列中，事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（链接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不一样的操做，每一个操做对应不一样的文件事件，可是 IO 多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。

Redis 服务端进程初始化的时候，会将 server socket 的 AE_READABLE 事件与链接应答处理器关联。

客户端 socket01 向 Redis 进程的 server socket 请求创建链接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该 socket 压入队列中。文件事件分派器从队列中获取 socket，交给链接应答处理器。链接应答处理器会建立一个能与客户端通讯的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。

假设此时客户端发送了一个 set key value 请求，此时 Redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将 socket01 压入队列，此时事件分派器从队列中获取到 socket01 产生的 AE_READABLE 事件，因为前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，所以事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在本身内存中完成 key value 的设置。操做完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。

若是此时客户端准备好接收返回结果了，那么 Redis 中的 socket01 会产生一个 AE_WRITABLE 事件，一样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操做的一个结果，好比 ok ，以后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。

这样便完成了一次通讯。关于 Redis 的一次通讯过程，推荐读者阅读《Redis 设计与实现——黄健宏》进行系统学习。

 

文件事件处理器的构成

图 IMAGE_CONSTRUCT_OF_FILE_EVENT_HANDLER 展现了文件事件处理器的四个组成部分， 它们分别是套接字、 I/O 多路复用程序、 文件事件分派器（dispatcher）、 以及事件处理器。

文件事件是对套接字操做的抽象， 每当一个套接字准备好执行链接应答（accept）、写入、读取、关闭等操做时， 就会产生一个文件事件。 由于一个服务器一般会链接多个套接字， 因此多个文件事件有可能会并发地出现。

I/O 多路复用程序负责监听多个套接字， 并向文件事件分派器传送那些产生了事件的套接字。

尽管多个文件事件可能会并发地出现， 但 I/O 多路复用程序老是会将全部产生事件的套接字都入队到一个队列里面， 而后经过这个队列， 以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字： 当上一个套接字产生的事件被处理完毕以后（该套接字为事件所关联的事件处理器执行完毕）， I/O 多路复用程序才会继续向文件事件分派器传送下一个套接字， 如图 IMAGE_DISPATCH_EVENT_VIA_QUEUE 。

文件事件分派器接收 I/O 多路复用程序传来的套接字， 并根据套接字产生的事件的类型， 调用相应的事件处理器。

服务器会为执行不一样任务的套接字关联不一样的事件处理器， 这些处理器是一个个函数， 它们定义了某个事件发生时， 服务器应该执行的动做。

I/O 多路复用程序的实现

Redis 的 I/O 多路复用程序的全部功能都是经过包装常见的 select 、 epoll 、 evport 和 kqueue 这些 I/O 多路复用函数库来实现的， 每一个 I/O 多路复用函数库在 Redis 源码中都对应一个单独的文件， 好比 ae_select.c 、 ae_epoll.c 、 ae_kqueue.c ， 诸如此类。

由于 Redis 为每一个 I/O 多路复用函数库都实现了相同的 API ， 因此 I/O 多路复用程序的底层实现是能够互换的， 如图 IMAGE_MULTI_LIB 所示。

Redis 在 I/O 多路复用程序的实现源码中用 #include 宏定义了相应的规则， 程序会在编译时自动选择系统中性能最高的 I/O 多路复用函数库来做为 Redis 的 I/O 多路复用程序的底层实现：

/* Include the best multiplexing layer supported by this system.  * The following should be ordered by performances, descending. */ #ifdef HAVE_EVPORT #include "ae_evport.c" #else #ifdef HAVE_EPOLL #include "ae_epoll.c" #else #ifdef HAVE_KQUEUE #include "ae_kqueue.c" #else #include "ae_select.c" #endif #endif #endif 

事件的类型

I/O 多路复用程序能够监听多个套接字的 ae.h/AE_READABLE 事件和 ae.h/AE_WRITABLE 事件， 这两类事件和套接字操做之间的对应关系以下：

• 当套接字变得可读时（客户端对套接字执行 write 操做，或者执行 close 操做）， 或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行 connect 操做）， 套接字产生 AE_READABLE 事件。
• 当套接字变得可写时（客户端对套接字执行 read 操做）， 套接字产生 AE_WRITABLE 事件。

I/O 多路复用程序容许服务器同时监听套接字的 AE_READABLE 事件和 AE_WRITABLE 事件， 若是一个套接字同时产生了这两种事件， 那么文件事件分派器会优先处理 AE_READABLE 事件， 等到 AE_READABLE 事件处理完以后， 才处理 AE_WRITABLE 事件。

这也就是说， 若是一个套接字又可读又可写的话， 那么服务器将先读套接字， 后写套接字。

API

ae.c/aeCreateFileEvent 函数接受一个套接字描述符、 一个事件类型、 以及一个事件处理器做为参数， 将给定套接字的给定事件加入到 I/O 多路复用程序的监听范围以内， 并对事件和事件处理器进行关联。

ae.c/aeDeleteFileEvent 函数接受一个套接字描述符和一个监听事件类型做为参数， 让 I/O 多路复用程序取消对给定套接字的给定事件的监听， 并取消事件和事件处理器之间的关联。

ae.c/aeGetFileEvents 函数接受一个套接字描述符， 返回该套接字正在被监听的事件类型：

• 若是套接字没有任何事件被监听， 那么函数返回 AE_NONE 。
• 若是套接字的读事件正在被监听， 那么函数返回 AE_READABLE 。
• 若是套接字的写事件正在被监听， 那么函数返回 AE_WRITABLE 。
• 若是套接字的读事件和写事件正在被监听， 那么函数返回 AE_READABLE | AE_WRITABLE 。

ae.c/aeWait 函数接受一个套接字描述符、一个事件类型和一个毫秒数为参数， 在给定的时间内阻塞并等待套接字的给定类型事件产生， 当事件成功产生， 或者等待超时以后， 函数返回。

ae.c/aeApiPoll 函数接受一个 sys/time.h/struct timeval 结构为参数， 并在指定的时间內， 阻塞并等待全部被 aeCreateFileEvent 函数设置为监听状态的套接字产生文件事件， 当有至少一个事件产生， 或者等待超时后， 函数返回。

ae.c/aeProcessEvents 函数是文件事件分派器， 它先调用 aeApiPoll 函数来等待事件产生， 而后遍历全部已产生的事件， 并调用相应的事件处理器来处理这些事件。

ae.c/aeGetApiName 函数返回 I/O 多路复用程序底层所使用的 I/O 多路复用函数库的名称： 返回 "epoll" 表示底层为 epoll 函数库， 返回"select" 表示底层为 select 函数库， 诸如此类。

文件事件的处理器

Redis 为文件事件编写了多个处理器， 这些事件处理器分别用于实现不一样的网络通信需求， 好比说：

• 为了对链接服务器的各个客户端进行应答， 服务器要为监听套接字关联链接应答处理器。
• 为了接收客户端传来的命令请求， 服务器要为客户端套接字关联命令请求处理器。
• 为了向客户端返回命令的执行结果， 服务器要为客户端套接字关联命令回复处理器。
• 当主服务器和从服务器进行复制操做时， 主从服务器都须要关联特别为复制功能编写的复制处理器。
• 等等。

在这些事件处理器里面， 服务器最经常使用的要数与客户端进行通讯的链接应答处理器、 命令请求处理器和命令回复处理器。

链接应答处理器

networking.c/acceptTcpHandler 函数是 Redis 的链接应答处理器， 这个处理器用于对链接服务器监听套接字的客户端进行应答， 具体实现为sys/socket.h/accept 函数的包装。

当 Redis 服务器进行初始化的时候， 程序会将这个链接应答处理器和服务器监听套接字的 AE_READABLE 事件关联起来， 当有客户端用sys/socket.h/connect 函数链接服务器监听套接字的时候， 套接字就会产生 AE_READABLE 事件， 引起链接应答处理器执行， 并执行相应的套接字应答操做， 如图 IMAGE_SERVER_ACCEPT_CONNECT 所示。

命令请求处理器

networking.c/readQueryFromClient 函数是 Redis 的命令请求处理器， 这个处理器负责从套接字中读入客户端发送的命令请求内容， 具体实现为 unistd.h/read 函数的包装。

当一个客户端经过链接应答处理器成功链接到服务器以后， 服务器会将客户端套接字的 AE_READABLE 事件和命令请求处理器关联起来， 当客户端向服务器发送命令请求的时候， 套接字就会产生 AE_READABLE 事件， 引起命令请求处理器执行， 并执行相应的套接字读入操做， 如图 IMAGE_SERVER_RECIVE_COMMAND_REQUEST 所示。

在客户端链接服务器的整个过程当中， 服务器都会一直为客户端套接字的 AE_READABLE 事件关联命令请求处理器。

命令回复处理器

networking.c/sendReplyToClient 函数是 Redis 的命令回复处理器， 这个处理器负责将服务器执行命令后获得的命令回复经过套接字返回给客户端， 具体实现为 unistd.h/write 函数的包装。

当服务器有命令回复须要传送给客户端的时候， 服务器会将客户端套接字的 AE_WRITABLE 事件和命令回复处理器关联起来， 当客户端准备好接收服务器传回的命令回复时， 就会产生 AE_WRITABLE 事件， 引起命令回复处理器执行， 并执行相应的套接字写入操做， 如图 IMAGE_SERVER_SEND_REPLY 所示。

当命令回复发送完毕以后， 服务器就会解除命令回复处理器与客户端套接字的 AE_WRITABLE 事件之间的关联。

一次完整的客户端与服务器链接事件示例

让咱们来追踪一次 Redis 客户端与服务器进行链接并发送命令的整个过程， 看看在过程当中会产生什么事件， 而这些事件又是如何被处理的。

假设一个 Redis 服务器正在运做， 那么这个服务器的监听套接字的 AE_READABLE 事件应该正处于监听状态之下， 而该事件所对应的处理器为链接应答处理器。

若是这时有一个 Redis 客户端向服务器发起链接， 那么监听套接字将产生 AE_READABLE 事件， 触发链接应答处理器执行： 处理器会对客户端的链接请求进行应答， 而后建立客户端套接字， 以及客户端状态， 并将客户端套接字的 AE_READABLE 事件与命令请求处理器进行关联， 使得客户端能够向主服务器发送命令请求。

以后， 假设客户端向主服务器发送一个命令请求， 那么客户端套接字将产生 AE_READABLE 事件， 引起命令请求处理器执行， 处理器读取客户端的命令内容， 而后传给相关程序去执行。

执行命令将产生相应的命令回复， 为了将这些命令回复传送回客户端， 服务器会将客户端套接字的 AE_WRITABLE 事件与命令回复处理器进行关联： 当客户端尝试读取命令回复的时候， 客户端套接字将产生 AE_WRITABLE 事件， 触发命令回复处理器执行， 当命令回复处理器将命令回复所有写入到套接字以后， 服务器就会解除客户端套接字的 AE_WRITABLE 事件与命令回复处理器之间的关联。

图 IMAGE_COMMAND_PROGRESS 总结了上面描述的整个通信过程， 以及通信时用到的事件处理器。

 

为啥 Redis 单线程模型也能效率这么高？

• 纯内存操做。
• 核心是基于非阻塞的 IO 多路复用机制。
• C 语言实现，通常来讲，C 语言实现的程序“距离”操做系统更近，执行速度相对会更快。
• 单线程反而避免了多线程的频繁上下文切换问题，预防了多线程可能产生的竞争问题。