如何单进程Redis可以支持10W以上qps

如何单进程Redis可以支持10W以上qps

事实上，服务器端只需要单线程可以达到非常高的处理能力，Redis 就是一个非常好的例子。仅仅靠单线程就可以支撑起每秒数万

QPS 的高处理能力。今天我们就来带大家看看 Redis 核心网络模块的内部实现，学习下 Redis 是如何做到如此的高性能的！

一、理解多路复用原理

在开始介绍 Redis 之前，我想有必要先来简单介绍下 epoll。

在传统的同步阻塞网络编程模型里（没有协程以前），性能上不来的根本原因在于进程线程都是笨重的家伙。让一个进(线)程只处理一个用户请求确确实实是有点浪费了。

先抛开高内存开销不说，在海量的网络请求到来的时候，光是频繁的进程线程上下文就让 CPU 疲于奔命了。

如果把进程比作牧羊人，一个进(线)程同时只能处理一个用户请求，相当于一个人只能看一只羊，放完这一只才能放下一只。如果同

时来了 1000 只羊，那就得 1000 个人去放，这人力成本是非常高的。

性能提升思路很简单，就是让很多的用户连接来复用同一个进(线)程，这就是多路复用。多路指的是许许多多个用户的网络连接。复用指的是对进(线)程的复用。换到牧羊人的例子里，就是一群羊只要一个牧羊人来处理就行了。

不过复用实现起来是需要特殊的 socket 事件管理机制的，最典型和高效的方案就是 epoll。放到牧羊人的例子来，epoll 就相当于一只牧羊犬。

在 epoll 的系列函数里， epoll_create 用于创建一个 epoll 对象，epoll_ctl 用来给 epoll 对象添加或者删除一个 socket。epoll_wait 就是查看它当前管理的这些 socket 上有没有可读可写事件发生。

当网卡上收到数据包后，Linux 内核进行一系列的处理后把数据放到 socket 的接收队列。然后会检查是否有 epoll 在管理它，如果是则在 epoll 的就绪队列中插入一个元素。epoll_wait 的操作就非常的简单了，就是到 epoll 的就绪队列上来查询有没有事件发生就行了。关于 epoll 这只“牧羊犬”的工作原理参见深入揭秘 epoll 是如何实现 IO 多路复用的 (Javaer 习惯把基于 epoll 的网络开发模型叫做

NIO)

在基于 epoll 的编程中，和传统的函数调用思路不同的是，我们并不能主动调用某个 API 来处理。因为无法知道我们想要处理的事

件啥时候发生。所以只好提前把想要处理的事件的处理函数注册到一个事件分发器上去。当事件发生的时候，由这个事件分发器调用回调函数进行处理。这类基于实现注册事件分发器的开发模式也叫

Reactor 模型。

理解了 epoll 原理后，我们再来实际看 Redis 具体是如何使用

epoll 的。直接在 Github 上就可以非常方便地获取 Redis 的源码。我们切到 5.0.0 版本来看单线程版本的实现

其中整个 Redis 服务的代码总入口在 src/server.c 文件中，我把入口函数的核心部分摘了出来，如下。

其实整个 Redis 的工作过程，就只需要理解清楚 main 函数中调用的 initServer 和 aeMain 这两个函数就足够了。

本节中我们重点介绍 initServer，在下一节介绍事件处理循环 aeMain。

在 initServer 这个函数内，Redis 做了这么三件重要的事情。

创建一个 epoll 对象

对配置的监听端口进行 listen

把 listen socket 让 epoll 给管理起来

1.创建 epoll 对象

本小节的逻辑看起来貌似不短，但其实只是创建了一个 epoll 对象出来而已。

创建 epoll 对象的逻辑在 aeCreateEventLoop 中，在创建完后，Redis

将其保存在 redisServer 的 aeEventLoop 成员中，以备后续使用。

我们来看 aeCreateEventLoop 详细逻辑。Redis 在操作系统提供的

epoll 对象基础上又封装了一个 eventLoop 出来，所以创建的时候是先申请和创建 eventLoop。

在 eventLoop 里，我们稍微注意一下 eventLoop->events，将来在各种事件注册的时候都会保存到这个数组里。

具体创建 epoll 的过程在 ae_epoll.c 文件下的 aeApiCreate 中。在这里，真正调用了 epoll_create。

2.绑定监听服务端口

我们再来看 Redis 中的 listen 过程，它在 listenToPort 函数中。虽然调用链条很长，但其实主要就是执行了个简单 listen 而已。

Redis 是支持开启多个端口的，所以在 listenToPort 中我们看到是启用一个循环来调用 anetTcpServer。在 anetTcpServer 中，逐步会

展开调用，直到执行到 bind 和 listen 系统调用。

3.注册事件回调函数

我们回头再看一下 initServer，它调用 aeCreateEventLoop 创建了 epoll，调用 listenToPort 进行了服务端口的 bind 和 listen。接着就开始调用 aeCreateFileEvent 来注册一个 accept 事件处理器。

我们来注意看调用 aeCreateFileEvent 时传的重要参数是

acceptTcpHandler，它表示将来在 listen socket 上有新用户连接到达的时候，该函数将被调用执行。我们来看 aeCreateFileEvent 具体代码。

函数 aeCreateFileEvent 一开始，从 eventLoop->events 获取了一个 aeFileEvent 对象。在 2.1 中我们介绍过 eventLoop->events 数组，注册的各种事件处理器会保存在这个地方。

接下来调用 aeApiAddEvent。这个函数其实就是对 epoll_ctl 的一个封装。主要就是实际执行 epoll_ctl EPOLL_CTL_ADD。

每一个 eventLoop->events 元素都指向一个 aeFileEvent 对象。在这个对象上，设置了三个关键东西

rfileProc：读事件回调

wfileProc：写事件回调

clientData：一些额外的扩展数据

将来 当 epoll_wait 发现某个 fd 上有事件发生的时候，这样

redis 首先根据 fd 到 eventLoop->events 中查找 aeFileEvent 对象，然后再看 rfileProc、wfileProc 就可以找到读、写回调处理函数。

回头看 initServer 调用 aeCreateFileEvent 时传参来看。

listen fd 对应的读回调函数 rfileProc 事实上就被设置成了

acceptTcpHandler，写回调没有设置，私有数据 client_data 也为 null。

三、Redis 事件处理循环

在上一节介绍完了 Redis 的启动初始化过程，创建了 epoll，也进行了绑定监听，也注册了 accept 事件处理函数为

acceptTcpHandler。

接下来，Redis 就会进入 aeMain 开始进行真正的用户请求处理了。在 aeMain 函数中，是一个无休止的循环。在每一次的循环中，要做如下几件事情。

通过 epoll_wait 发现 listen socket 以及其它连接上的可读、可写事件。

若发现 listen socket 上有新连接到达，则接收新连接，并追加到

epoll 中进行管理。

若发现其它 socket 上有命令请求到达，则读取和处理命令，把命令结果写到缓存中，加入写任务队列。

每一次进入 epoll_wait 前都调用 beforesleep 来将写任务队列中的数据实际进行发送。

如若有首次未发送完毕的，当写事件发生时继续发送。

以上就是 aeMain 函数的核心逻辑所在，接下来我们分别对如上提到的四件事情进行详细的阐述。

1. epoll_wait 发现事件

Redis 不管有多少个用户连接，都是通过 epoll_wait 来统一发现和管理其上的可读（包括 liisten socket 上的 accept事件）、可写事件的。甚至连 timer，也都是交给 epoll_wait 来统一管理的。

每当 epoll_wait 发现特定的事件发生的时候，就会调用相应的事先注册好的事件处理函数进行处理。我们来详细看

aeProcessEvents 对 epoll_wait 的封装。

2.处理新连接请求

我们假设现在有新用户连接到达了。前面在我们看到 listen

socket 上的 rfileProc 注册的是 acceptTcpHandler。也就是说，如果有连接到达的时候，会回调到 acceptTcpHandler。

在 acceptTcpHandler 中，主要做了几件事情：

调用 accept 系统调用把用户连接给接收回来

为这个新连接创建一个唯一 redisClient 对象

将这个新连接添加到 epoll，并注册一个读事件处理函数

接下来让我们看上面这三件事情都分别是如何被处理的。

关于 aeCreateFileEvent 的处理过程这里就不赘述了，详情参见

2.3 节。其效果就是将该用户连接 socket fd 对应的读处理函数设置为 readQueryFromClient, 并且设置私有数据为 redisClient c。

3.处理客户连接上的可读事件

现在假设该用户连接有命令到达了，就假设用户发送了GET

XXXXXX_KEY 命令。那么在 Redis 的时间循环中调用 epoll_wait 发现该连接上有读时间后，会调用在上一节中讨论的为其注册的读处理函数 readQueryFromClient。

在读处理函数 readQueryFromClient 中主要做了这么几件事情。

解析并查找命令

调用命令处理

添加写任务到队列

将输出写到缓存等待发送

我们来详细地看 readQueryFromClient 的代码。在

readQueryFromClient 中会调用 processInputBuffer，然后进入

processCommand 对命令进行处理。其调用链如下：

我们再来详细看 processCommand 。

我们先忽略 queueMultiCommand，直接看核心命令处理方法

call。

在 server.c 中定义了每一个命令对应的处理函数

对于 get 命令来说，其对应的命令处理函数就是 getCommand。也就是说当处理 GET 命令执行到 c->cmd->proc 的时候会进入到

getCommand 函数中来。

getGenericCommand 方法会调用 lookupKeyReadOrReply 来从内存中查找对应的 key值。如果找不到，则直接返回 C_OK；如果找到了，调用 addReplyBulk 方法将值添加到输出缓冲区中。

其主题是调用 addReply 来设置回复数据。在 addReply 方法中做了两件事情：

prepareClientToWrite 判断是否需要返回数据，并且将当前 client

添加到等待写返回数据队列中。

调用 _addReplyToBuffer 和 _addReplyObjectToList 方法将返回值写入到输出缓冲区中，等待写入 socekt

先来看 prepareClientToWrite 的详细实现：

其中

s_pending_write 就是我们说的任务队列，队列中的每一个元素都是有待写返回数据的 client 对象。在

prepareClientToWrite 函数中，把 client 添加到任务队列

s_pending_write 里就算完事。

接下再来 _addReplyToBuffer，该方法是向固定缓存中写，如果

写不下的话就继续调用 _addReplyStringToList 往链表里写。简单起见，我们只看 _addReplyToBuffer 的代码。

sleep 处理写任务队列

回想在 aeMain 函数中，每次在进入 aeProcessEvents 前都需要先进行 beforesleep 处理。这个函数名字起得怪怪的，但实际上大有用处。

该函数处理了许多工作，其中一项便是遍历发送任务队列，并将

client 发送缓存区中的处理结果通过 write 发送到客户端手中。

我们来看下 beforeSleep 的实际源码。

在

handleClientsWithPendingWrites 中，遍历了发送任务队列

s_pending_write，并调用 writeToClient 进行实际的发送处理。

值得注意的是，发送 write 并不总是能一次性发送完的。假如要发送的结果太大，而系统为每个 socket 设置的发送缓存区又是有限的。

在这种情况下，clientHasPendingReplies 判断仍然有未发送完的数据的话，就需要注册一个写事件处理函数到 epoll 上。等待 epoll

发现该 socket 可写的时候再次调用 sendReplyToClient进行发送。

writeToClient 中的主要逻辑就是调用 write 系统调用让内核帮其把数据发送出去即可。由于每个命令的处理结果大小是不固定的。

所以 Redis 采用的做法用固定的 buf + 可变链表来储存结果字符串。这里自然发送的时候就需要分别对固定缓存区和链表来进行发送了。

四、高性能 Redis 网络原理总结

Redis 服务器端只需要单线程可以达到非常高的处理能力，每秒可以达到数万 QPS 的高处理能力。如此高性能的程序其实就是对

Linux 提供的多路复用机制 epoll 的一个较为完美的运用而已。

在 Redis 源码中，核心逻辑其实就是两个，一个是 initServer 启动服务，另外一个就是 aeMain 事件循环。

在 initServer 这个函数内，Redis 做了这么三件重要的事情。

创建一个 epoll 对象

对配置的监听端口进行 listen

把 listen socket 让 epoll 给管理起来

在 aeMain 函数中，是一个无休止的循环，它是 Redis 中最重要的部分。在每一次的循环中，要做的事情可以总结为如下图。

通过 epoll_wait 发现 listen socket 以及其它连接上的可读、可写事件

若发现 listen socket 上有新连接到达，则接收新连接，并追加到

epoll 中进行管理

若发现其它 socket 上有命令请求到达，则读取和处理命令，把命令结果写到缓存中，加入写任务队列

每一次进入 epoll_wait 前都调用 beforesleep 来将写任务队列中的数据实际进行发送

其实事件分发器还处理了一个不明显的逻辑，那就是如果

beforesleep 在将结果写回给客户端的时候，如果由于内核 socket 发送缓存区过小而导致不能一次发送完毕的时候，也会注册一个写事件处理器。等到 epoll_wait 发现对应的 socket 可写的时候，再执行

write 写处理。

整个 Redis 的网络核心模块就在咱们这一篇文章中都叙述透了（剩下的 Redis 就是对各种数据结构的建立和处理了）