Redis之线程模型
1、前言
Redis4.0版本之后开始使用多线程，之前使用的是单线程。无论是使用单线程模型还是多线程模型，这两个设计上的决定都是为了更好地提升 Redis 的开发效率、运行性能。虽然 Redis 在较新的版本中引入了多线程，不过是在部分命令上引入的，其中包括非阻塞的删除操作，在整体的架构设计上，主处理程序还是单线程模型的。
2、线程模型
Redis 基于 Reactor 模式开发了自己的网络事件处理器： 这个处理器被称为文件事件处理器（file event handler），由套接字、I/O多路复用程序、文件事件分派器（dispatcher），事件处理器四部分组成。
文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
虽然文件事件处理器以单线程方式运行， 但通过使用 I/O 多路复用程序来监听多个套接字， 文件事件处理器既实现了高性能的网络通信模型， 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接， 这保持了 Redis 内部单线程设计的简单性。
Redis服务端通过Socket与客户端连接。每当一个套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时，就会产生一个文件事件。因为一个服务器通常会连接多个套接字， 所以多个文件事件有可能会并发地出现。比如，当socket变得可读时，socket就会产生一个 AE_READABLE事件；当socket变得可写的时候，socket会产生一个 AE_WRITABLE事件。
2.1、文件事件处理器的构成
文件事件处理器的四个组成部分， 它们分别是套接字、 I/O 多路复用程序、 文件事件分派器（dispatcher）、 以及事件处理器。
文件事件是对套接字操作的抽象， 每当一个套接字准备好执行连接应答（accept）、写入、读取、关闭等操作时， 就会产生一个文件事件。 因为一个服务器通常会连接多个套接字， 所以多个文件事件有可能会并发地出现。
I/O 多路复用程序负责监听多个套接字， 并向文件事件分派器传送那些产生了事件的套接字。
尽管多个文件事件可能会并发地出现， 但 I/O 多路复用程序总是会将所有产生事件的套接字都入队到一个队列里面， 然后通过这个队列， 以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字： 当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O 多路复用程序才会继续向文件事件分派器传送下一个套接字。
文件事件分派器接收 I/O 多路复用程序传来的套接字， 并根据套接字产生的事件的类型， 调用相应的事件处理器。服务器会为执行不同任务的套接字关联不同的事件处理器， 这些处理器是一个个函数， 它们定义了某个事件发生时， 服务器应该执行的动作。
2.2、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 多路复用程序的底层实现是可以互换的， 如图所示。
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
2.3、事件的类型与调度
服务器需要处理两类事件：文件事件，时间事件。
（1）文件事件：Redis服务器对套接字的操作，当一个套接字准备执行连接、读、写、关闭等操作时就会产生一个文件事件。文件事件分为AE_READABLE和AE_WRITABLE两类。
- 当套接字变得可读时（客户端对套接字执行 write 操作，或者执行 close 操作）， 或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行 connect 操作）， 套接字产生AE_READABLE事件。
- 当套接字变得可写时（客户端对套接字执行 read 操作）， 套接字产生AE_WRITABLE事件。
- 更新服务器的各类统计信息，如时间、内存占用、数据库占用情况等。
- 清理数据库中的过期键值对。
- 关闭和清理连接失效的客户端。
- 尝试进行AOF或RDB持久化操作。
- 如果服务器是主服务器，那么对从服务器进行定期同步。
- 如果处于集群模式，对集群进行定期执行同步和连接测试。
- Redis2.6版本，服务器默认serverCron每秒运行10次，平均每隔100毫秒运行一次。Redis2.8版本之后，通过hz调整每秒执行次数。
- 如果套接字没有任何事件被监听， 那么函数返回 AE_NONE 。
- 如果套接字的读事件正在被监听， 那么函数返回 AE_READABLE 。
- 如果套接字的写事件正在被监听， 那么函数返回 AE_WRITABLE 。
- 如果套接字的读事件和写事件正在被监听， 那么函数返回 AE_READABLE | AE_WRITABLE 。
- 为了对连接服务器的各个客户端进行应答， 服务器要为监听套接字关联连接应答处理器。
- 为了接收客户端传来的命令请求， 服务器要为客户端套接字关联命令请求处理器。
- 为了向客户端返回命令的执行结果， 服务器要为客户端套接字关联命令回复处理器。
- 当主服务器和从服务器进行复制操作时， 主从服务器都需要关联特别为复制功能编写的复制处理器。
- 注意1：只有当上一个套接字产生的事件被所关联的事件处理器执行完毕，I/O多路复用程序才会继续向文件事件分派器传送下一个套接字，所以对每个命令的执行时间是有要求的，如果某个命令执行过长，会造成其他命令的阻塞。所以慎用O(n)命令，Redis是面向快速执行场景的数据库。
- 注意2：命令的并发性。Redis是单线程处理命令，命令会被逐个被执行，假如有3个客户端命令同时执行，执行顺序是不确定的，但能确定不会有两条命令被同时执行，所以两条incr命令无论怎么执行最终结果都是2。
- 假设一个 Redis 服务器正在运作， 那么这个服务器的监听套接字的 AE_READABLE 事件应该正处于监听状态之下， 而该事件所对应的处理器为连接应答处理器。
- 如果这时有一个 Redis 客户端向服务器发起连接， 那么监听套接字将产生 AE_READABLE 事件， 触发连接应答处理器执行： 处理器会对客户端的连接请求进行应答， 然后创建客户端套接字， 以及客户端状态， 并将客户端套接字的 AE_READABLE 事件与命令请求处理器进行关联， 使得客户端可以向主服务器发送命令请求。
- 之后， 假设客户端向主服务器发送一个命令请求， 那么客户端套接字将产生 AE_READABLE 事件， 引发命令请求处理器执行， 处理器读取客户端的命令内容， 然后传给相关程序去执行。
- 执行命令将产生相应的命令回复， 为了将这些命令回复传送回客户端， 服务器会将客户端套接字的 AE_WRITABLE 事件与命令回复处理器进行关联： 当客户端尝试读取命令回复的时候， 客户端套接字将产生 AE_WRITABLE 事件， 触发命令回复处理器执行， 当命令回复处理器将命令回复全部写入到套接字之后， 服务器就会解除客户端套接字的 AE_WRITABLE 事件与命令回复处理器之间的关联。
//客户端状态的关键属性：
typedef struct redisClient {
//……
sds querybuf;
robj **argv;
int argc;
struct redisCommand *cmd;
char buf[REDIS_REPLY_CHUNK_BYTES];
int bufpos;
list *reply;
//……
} redisClient;
一个命令请求从发送到获得回复的过程：
1、发送命令请求：
当客户端使用connect函数连接到服务器时，服务器就会调用连接事件处理器，为客户端创建相应的客户端状态，并将这个新的客户端状态添加到服务器状态结构clients链表的末尾。
当用户在客户端中键入一个命令请求时，客户端会将这个命令请求转换成协议格式，然后通过连接到服务器的套接字，将协议格式的命令请求发送给服务器。
2、读取命令请求：
当客户端与服务器之间的连接套接字因为客户端的写入而变得可读时，服务器将调用命令请求处理器来执行以下操作：
- 读取套接字中协议格式的命令请求，并将其保存到客户端状态的输入缓冲区querybuf。
- 对输入缓冲区中的命令请求进行分析，提取出命令请求中包含的命令参数，以及命令参数的个数，然后分别将参数和参数个数保存到客户端状态的argv和argc属性。
- 调用命令执行器，执行客户端指定的命令。
- 命令执行器要做的第一件事就是根据客户端状态的argv[0]参数，在命令表中查找参数所指定的命令，并将找到的命令保存到客户端状态的cmd属性中。
- 到目前为止，服务器已经将执行命令所需的命令实现函数（cmd）、参数（argv）、参数个数（argc）都收集齐了，但在真正执行命令前，程序还需要进行一些预备操作，从而确保命令可以正确、顺利地被执行：检查客户端状态的cmd指针是否执行NULL、检查命令请求所给定的参数个数是否正确、检查客户端是否已经通过了身份验证...
- 被调用的命令实现函数会执行指定的操作，并产生相应的命令回复，这些回复会被保存在客户端状态的输出缓冲区中（buf属性和reply属性），之后实现函数还会为客户端的套接字关联命令回复处理器，这个处理器负责将命令回复返回给客户端。
- 如果服务器开启了慢查询日志功能，那么慢查询日志模块会检查是否需要为刚刚执行完的命令请求添加一条新的慢查询日志。
- 根据刚刚执行命令所耗费的时长，更新被执行命令的redisCommand结构的milliseconds属性，并将命令的redisCommand结构的calls计数器的值加1。
- 如果服务器开启AOF持久化功能，那么AOF持久化模块会将刚刚执行的命令请求写入到AOF缓冲区。
- 如果有其他服务器正在复制当前这个服务器，那么服务器会将刚刚执行的命令传播给所有从服务器。
- 当客户端套接字变为可写状态时，服务器就会执行命令回复处理器，将保存在客户端输出缓冲区中的命令回复发送给客户端。当命令回复发送完毕之后，回复处理器会清空客户端状态的输出缓冲区，为处理下一个命令请求做好准备。
- 当客户端接收到协议格式的命令回复之后，它会将这些回复转换成人们可以识别的可读的格式。
- 如果用户为这些属性的相应选项指定了新的值，那么服务器就使用用户指定的值来更新相应的属性。
- 如果用户没有为属性的相应选项设置新值，那么服务器就沿用为initServerConfig函数为属性设置的默认值。
- 如果服务器启用了AOF持久化功能，那么服务器使用AOF文件来还原数据库状态
- 相反地，如果服务器没有启用AOF持久化功能，那么服务器使用RDB文件来还原数据库状态