Redis 主要是通过三个方面来满足这样高效吞吐量的性能需求

高效的数据结构

多路复用 IO 模型

事件机制

1、高效的数据结构

Redis 支持的几种高效的数据结构 string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）

以上几种对外暴露的数据结构它们的底层编码方式都是做了不同的优化的，不细说了，不是本文重点。

2、多路复用 IO 模型

假设某一时刻与 Redis 服务器建立了 1 万个长连接，对于阻塞式 IO 的做法就是，对每一条连接都建立一个线程来处理，那么就需要 1万个线程，同时根据我们的经验对于 IO 密集型的操作我们一般设置，线程数 = 2 * CPU 数量 + 1，对于 CPU 密集型的操作一般设置线程 = CPU 数量 + 1。

当然各种书籍或者网上也有一个详细的计算公式可以算出更加合适准确的线程数量，但是得到的结果往往是一个比较小的值，像阻塞式 IO 这也动则创建成千上万的线程，系统是无法承载这样的负荷的更加弹不上高效的吞吐量和服务了。

而多路复用 IO 模型的做法是，用一个线程将这一万个建立成功的链接陆续的放入 event_poll，event_poll 会为这一万个长连接注册回调函数，当某一个长连接准备就绪后（建立建立成功、数据读取完成等），就会通过回调函数写入到 event_poll 的就绪队列 rdlist 中，这样这个单线程就可以通过读取 rdlist 获取到需要的数据。

需要注意的是，除了异步 IO 外，其它的 I/O 模型其实都可以归类为阻塞式 I/O 模型，不同的是像阻塞式 I/O 模型在第一阶段读取数据的时候，如果此时数据未准备就绪需要阻塞，在第二阶段数据准备就绪后需要将数据从内核态复制到用户态这一步也是阻塞的。而多路复用 IO 模型在第一阶段是不阻塞的，只会在第二阶段阻塞。

通过这种方式，就可以用 1 个或者几个线程来处理大量的连接了，极大的提升了吐吞量

3、事件机制

Redis 客户端与 Redis 服务端建立连接，发送命令，Redis 服务器响应命令都是需要通过事件机制来做的，如下图

首先 redis 服务器运行，监听套接字的 AE_READABLE 事件处于监听的状态下，此时连接应答处理器工作

客户端与 Redis 服务器发起建立连接，监听套接字产生 AE_READABLE 事件，当 IO 多路复用程序监听到其准备就绪后，将该事件压入队列中，由文件事件分派器获取队列中的事件交于连接应答处理器工作处理，应答客户端建立连接成功，同时将客户端 socket 的 AE_READABLE 事件压入队列由文件事件分派器获取队列中的事件交命令请求处理器关联

客户端发送 set key value 请求，客户端 socket 的 AE_READABLE 事件，当 IO 多路复用程序监听到其准备就绪后，将该事件压入队列中，由文件事件分派器获取队列中的事件交于命令请求处理器关联处理

命令请求处理器关联处理完成后，需要响应客户端操作完成，此时将产生 socket 的 AE_WRITEABLE 事件压入队列，由文件事件分派器获取队列中的事件交于命令恢复处理器处理，返回操作结果，完成后将解除 AE_WRITEABLE 事件与命令恢复处理器的关联

reactor模式

大体上可以说 Redis 的工作模式是，reactor 模式配合一个队列，用一个 serverAccept 线程来处理建立请求的链接，并且通过 IO 多路复用模型，让内核来监听这些 socket，一旦某些 socket 的读写事件准备就绪后就对应的事件压入队列中，然后 worker 工作，由文件事件分派器从中获取事件交于对应的处理器去执行，当某个事件执行完成后文件事件分派器才会从队列中获取下一个事件进行处理。

可以类比在 netty 中，我们一般会设置 bossGroup 和 workerGroup 默认情况下 bossGroup 为 1，workerGroup = 2 * cpu 数量，这样可以由多个线程来处理读写就绪的事件，但是其中不能有比较耗时的操作如果有的话需要将其放入线程池中，不然会降低其吐吞量。在 Redis 中我们可以看做这二者的值都是 1。

4、redis核心实现

文件事件处理器

消息处理流程

文件事件处理器使用I/O多路复用(multiplexing)程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。

当被监听的套接字准备好执行连接应答(accept)、读取(read)、写入(write)、关闭(close)等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都推到一个队列里面，然后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， 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多路复用程序的底层实现是可以互换的，如下图所示。

有关epoll的详细讲解，可以点击查看，彻底搞懂epoll高效运行的原理

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

文件事件的类型

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 事件。这也就是说，如果一个套接字又可读又可写的话，那么服务器将先处理读套接字，后处理写套接字。

文件事件的处理器

Redis为文件事件编写了多个处理器，这些事件处理器分别用于实现不同的网络通讯需求，常用的处理器如下：

为了对连接服务器的各个客户端进行应答， 服务器要为监听套接字关联连接应答处理器。

为了接收客户端传来的命令请求， 服务器要为客户端套接字关联命令请求处理器。

为了向客户端返回命令的执行结果， 服务器要为客户端套接字关联命令回复处理器。

连接应答处理器

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

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

命令请求处理器

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

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

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

命令回复处理器

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

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

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

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

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

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

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

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

为什么说存储的值不宜过大

比如一个 string key = a，存储了 500MB，首先读取事件压入队列中，文件事件分派器从中获取到后，交于命令请求处理器处理，此处就涉及到从磁盘中加载 500MB。

比如是普通的 SSD 硬盘，读取速度 200MB/S，那么需要 2.5S 的读取时间，在内存中读取数据比较快比如 DDR4 中 50G/秒，读取 500MB 需要 100 毫秒左右。

线程的库一般默认 10 毫秒就算慢查询了，大部分的指令执行时间都是微秒级别，此时其它 socket 所有的请求都将处于等待过程中，就会导致阻塞了 100 毫秒，同时又会占用较大的带宽导致吞吐量进一步下降。