破玩意 | Redis 为什么那么快

男娘i 2022-10-16 09:36 170阅读 0赞

低并发编程

战略上藐视技术，战术上重视技术

我是个 redis 服务，我马上就要启动了

因为我的主人正在控制台输入：

./redis-server

## **宏观上看下我的流程** ##

突然，主人按下了回车键，不得了了。

shell 程序把我的程序加载到了内存，开始执行我的 main 方法，一切就从这里开始了。

int main(int argc, char **argv) {
       ...
       initServer();
        ...
       aeCreateFileEvent(fd, acceptHandler, ...);
       ...
       aeMain();
       ...
    }

不要觉得我这里很复杂，其实主要就三大步。

**第一步，**我通过 **listenToPort()** 方法创建了一个 TCP 连接。

![3ba7297c19663f662e36ad226fc8ab78.png][]

我的这个方法真是见名知意，而且如果展开看就更会发现没什么神秘的，就是 **socket bind listen** 标准三步走，建立了一个 TCP 监听，返回了一个文件描述符 fd。

**第二步，**我通过 **aeCreateFileEvent()** 方法，将上面那个创建了 TCP 连接返回的文件描述符 fd，加入到一个叫 **aeFileEvent**的链表中。

![208cdfbcac2854af2a25d5dc62b53b7b.png][]

同时将这个文件描述符绑定一个函数 **acceptHandler**，这样当有客户端连接进来时，便会执行这个函数。

![9eaa222ec35ed286bb753bdc6bcb9a7b.png][]

第三步，我通过 **aeMain()** 方法，将上面的 aeFileEvent 链表中的文件描述符，统统作为 select 的入参，这是 **IO 多路复用模式**，如果不太了解的同学请阅读，《[你管这破玩意叫 IO 多路复用？][IO]》。

![f73c73ce512c0a8b125ea2f793bfba62.png][]

好了，其实就是开启了一个 TCP 监听，然后如果有客户端进来的话，让他执行 acceptHandler 函数而已。

之后我就一直死等着客户端连接了。

void aeMain(aeEventLoop *eventLoop)
    {
        eventLoop->stop = 0;
        while (!eventLoop->stop)
            aeProcessEvents(eventLoop, AE_ALL_EVENTS);
    }

![5539265b5bf540d5c59318edde71b27a.gif][]

## **展开体验下我的具体工作** ##

此时，另外一个人启动了一个 redis-client，连接到了我。

redis-cli -h host -p port

那么我头上的 fd 就会感知有数据读入，并执行 acceptHandler 方法。

static void acceptHandler(...) {
       ...
        cfd = anetAccept(...);
       ...
        c = createClient(cfd))
       ...
    }

可以看到，当有新客户端连接进来时，便会调用 **createClient** 创建一个专属的 client 为其服务。

static redisClient *createClient(int fd) {
       ...
       aeCreateFileEvent(c->fd, readQueryFromClient, ...);
       ...
    }

这里又可以看到，所谓的专属服务，其实仍然是这个 **aeCreateFileEvent** 函数。

这个上面说了，这个函数的功能就是把文件描述符挂在链表上，然后分配一个处理函数。

当然，这回的处理函数不再是处理新客户端连接的 acceptHandler，而是处理具体客户端传来的 redis 命令的函数 **readQueryFromClient**。

![b5b7ce348b2d14d9efdfda4fd6f80c07.png][]

不难想象，如果再来一个客户端，又来一个客户端... 那么不断将新客户端的文件描述符挂上去即可，而监听新客户端连接的，始终是最上面那个文件描述符。

![b87fef4d76772ddc3c2a256aad8f479d.png][]

好了，服务端开启了监听，客户端也连上了服务端，此时我仍然在死等状态，只不过等的不只是新客户端连接到达，还在等待已经连接上的客户端发来命令。

![d7dcd2c9235fe4d71fc8a4de6a26341a.gif][]

请注意，这里的死等，只有一个线程，循环调用 **aeProcessEvents** 函数，用 select 的方式监听多个文件描述符。放上刚刚 main 方法的第三步，帮大家回忆一下。

void aeMain(aeEventLoop *eventLoop)
    {
        eventLoop->stop = 0;
        while (!eventLoop->stop)
            aeProcessEvents(eventLoop, AE_ALL_EVENTS);
    }

当有新客户端建立连接时，会触发 acceptHandler 函数执行，多出一个等待数据的描述符。

![6087cc806f7d45a52cf84e7b840e9e04.gif][]

当有客户端数据传来时，会触发 **readQueryFromClient** 函数执行，完成这个命令的操作。

![f8a20803df74ed405da8d1eff0cae1b6.gif][]

注意，由于**只有一个线程在监听这些描述符**，并做处理。所以即使客户端并发地发送命令，后面仍然是依次取出命令，**顺序执行**。

![ac18ac2b1f1fb0d2a17f200cbe3d5e46.gif][]

这也就是我们常常说的，**redis 是单线程的**，命令与命令之间是顺序执行，无需考虑线程安全的问题。

## **为了方便大家吹牛，我来拔高一下** ##

大家发现没，我的启动过程，其实就分成两个大的部分。

**一个是监听客户端的请求**，就是用 IO 多路复用的方式，监听多个文件描述符，就刚刚那个 aeMain() 方法干的事嘛。

**一个是执行相应的函数去处理这个请求**，具体执行什么函数就是出现多次的 aeCreateFileEvent() 方法去绑定的，这个相应的函数说得高大上一点，叫做**事件处理器**。

![6766c6bb7df6c21f893e116106c91556.png][]

这里所谓的**连接应答处理器**，就是刚刚监听连接的文件描述符所绑定的函数 acceptHandler。

所谓的**命令请求处理器**，就是监听客户端命令（读事件）的文件描述符绑定的函数 readQueryFromClient。

所谓的**命令回复处理器**，就是后面要提到的，监听客户端响应（写事件）的文件描述符绑定的函数 sendReplyToClient。

这种一个负责响应 IO 事件，一个负责交给相应的事件处理器去处理，就叫做 **Reactor 模式**。

**Redis 正是基于 Reactor 模式开发了自己的文件事件处理器，实现了高性能的网络通信模型，并且保持了 Redis 内部单线程设计的简单性**。

有点担心这句话吹牛的逼格不够，其实我是参考了《Redis 设计与实现》，截图给大家。

![b44cb429e2c60201a831e9a5fbeeff28.png][]

## **具体怎么执行一个 Redis 命令** ##

现在，我们通过一个已建立好连接的客户端，发一个 redis 命令。

<client 6379> set dibingfa niubi

此时 **readQueryFromClient** 函数将被执行。

这个函数会去一张表中寻找命令所对应的函数，这部分用的编码技巧叫命令模式。

static struct redisCommand cmdTable[] = {
        {"get",getCommand,2,REDIS_CMD_INLINE},
        {"set",setCommand,3,REDIS_CMD_BULK|REDIS_CMD_DENYOOM},
        {"setnx",setnxCommand,3,REDIS_CMD_BULK|REDIS_CMD_DENYOOM},
        {"del",delCommand,-2,REDIS_CMD_INLINE},
        {"exists",existsCommand,2,REDIS_CMD_INLINE},
       ...
    }

找到了 set 命令对应的函数就是 **setCommand**。

这个函数，最终就会一步步地将 key 和 value 分别存储起来，这部分的源码细节，可以阅读我之前的文章，[《Redis 数据结构之字符串的那些骚操作》][Redis]。

而关于 redis 数据结构与底层对应的编码结构，可以阅读我之前的文章，[《面试官问我 redis 的数据类型，我回答了 8 种》][redis _ 8]。

处理完命令后，就要发送响应给客户端了。

static void setCommand(redisClient *c) {
       ...
        addReply(c, nx ? shared.cone : shared.ok);
    }

这个响应，并不是直接同步写回去，当然也不是开启一个线程去异步写回去。

它仍然是调用那个万恶的 **aeCreateFileEvent** 函数，将 **sendReplyToClient** 函数挂在需要响应的客户端连接的文件描述符上。

static void addReply(redisClient *c, robj *obj) {
       ...
        aeCreateFileEvent(server.el, c->fd, AE_WRITABLE,
        sendReplyToClient, c, NULL) == AE_ERR);
    }

好了，这回上一小节挖的坑，终于补上了。

以上这些个破玩意，就是我的启动过程啦，我是不是很可爱。

![7839ee99c078efe0097a0c6de0e5c610.gif][]

## **后记** ##

整篇文章我好像没讲 Redis 为啥那么快，因为我感觉这个问题问得不好。

你可以从接收网络请求的 IO 多路复用角度说起，也可以从事件处理器驱动的 Reactor 模式说起，还可以从具体处理命令时的数据结构说起，比如单单是字符串背后的 sds 其实就做了很多的巧妙设计。

如果我是面试官，我会具体让面试者聊聊 Redis 的启动流程，或者 Redis 处理命令的整个流程。

这里面可挖的点挺多的，如果能谈笑风生，那自然是技术水平还不错。

另外，你会发现本文出现的很多唬人的术语，比如 Reactor 模式，事件处理器等，看一遍 Redis 源码后你会发现真的非常简单。

毫不客气地说，一切丝毫不谈具体实现，和你堆砌一大堆唬人名词的文章或者人，都是在耍流氓。

本文我参考的是 Redis3.0.0 源码，但成文时用的讲解代码是 Redis1.0.0，整个网络模块的设计是完全一样的。

![929105a86f737e2a61dc80137c511b7a.png][]

**专属附赠**

我整理了一份 Redis 启动流程的极简版附注释代码的精美 PDF。

![c0e6f84e8def0a26b6c9481431c3c65b.png][]

这份PDF， 大家可以加 闪客Sun 的好友获取（低并发编程 菜单栏），哈哈哈。

[3ba7297c19663f662e36ad226fc8ab78.png]: /images/20221014/0472bcd36cbd49239762c85fccfdcb78.png
[208cdfbcac2854af2a25d5dc62b53b7b.png]: /images/20221014/437cd4a9f5dc4d7f96fd7db4648e1ae5.png
[9eaa222ec35ed286bb753bdc6bcb9a7b.png]: /images/20221014/29640c0ff04843f8ac112bfe589f203b.png
[IO]: http://mp.weixin.qq.com/s?__biz=Mzk0MjE3NDE0Ng%3D%3D&chksm=c2c5967ff5b21f69030636334f6a5a7dc52c0f4de9b668f7bac15b2c1a2660ae533dd9878c7c&idx=1&mid=2247494866&scene=21&sn=0ebeb60dbc1fd7f9473943df7ce5fd95#wechat_redirect
[f73c73ce512c0a8b125ea2f793bfba62.png]: /images/20221014/9d4b0703ccea42ea99e849eb150d505a.png
[5539265b5bf540d5c59318edde71b27a.gif]: /images/20221014/9f5e496f779c4f78b09a3b2b906335ff.png
[b5b7ce348b2d14d9efdfda4fd6f80c07.png]: /images/20221014/3182e3c6112444b8be9ba3546efe6e54.png
[b87fef4d76772ddc3c2a256aad8f479d.png]: /images/20221014/cd7ee8f8834e4bd9bab84bbec842d37d.png
[d7dcd2c9235fe4d71fc8a4de6a26341a.gif]: /images/20221014/b65ec3825a1b4ff8b0280ef5c52ebcc1.png
[6087cc806f7d45a52cf84e7b840e9e04.gif]: /images/20221014/595f4106990f47ccb6a1ed4e8913ece4.png
[f8a20803df74ed405da8d1eff0cae1b6.gif]: /images/20221014/9f7369ffeeaa49cc8bfb8d6a9346da4f.png
[ac18ac2b1f1fb0d2a17f200cbe3d5e46.gif]: /images/20221014/6bd41c24372f4e5cb99a26f26896bf93.png
[6766c6bb7df6c21f893e116106c91556.png]: /images/20221014/8c0336eac7704eaab5a7463abb949346.png
[b44cb429e2c60201a831e9a5fbeeff28.png]: /images/20221014/ecd9b0afe4804c2182375ea14e136cac.png
[Redis]: http://mp.weixin.qq.com/s?__biz=Mzk0MjE3NDE0Ng%3D%3D&chksm=c2c67b7af5b1f26c82e7b783cea62c7ff8fc2e221c6e69ea91397acdf982d6103ccf3c83e202&idx=1&mid=2247483863&scene=21&sn=2aeaf789cb3bc4d9968662527e8ec6f1#wechat_redirect
[redis _ 8]: http://mp.weixin.qq.com/s?__biz=Mzk0MjE3NDE0Ng%3D%3D&chksm=c2c67b77f5b1f261b5595c7b5de1595b41f5aacad199dfa14a30ab1171503b6afd78321338ad&idx=1&mid=2247483866&scene=21&sn=d426cb1c3a4f754d560af044b9e00f2c#wechat_redirect
[7839ee99c078efe0097a0c6de0e5c610.gif]: /images/20221014/6a1d764a32124da59e60270403ec172f.png
[929105a86f737e2a61dc80137c511b7a.png]: /images/20221014/1ddec6df2dd54cb498840ce55adf5171.png
[c0e6f84e8def0a26b6c9481431c3c65b.png]: /images/20221014/90c9783a367b4884bcbbef2ac3fc72ae.png