本文来自微信公众号：低并发编程 （ID：dibingfa），原文标题：《破玩意 | Redis 为什么那么快》，作者：闪客
我是个 redis 服务，我马上就要启动了
因为我的主人正在控制台输入：
/redis-server
宏观上看下我的流程
突然，主人按下了回车键，不得了了。
shell 程序把我的程序加载到了内存，开始执行我的 main 方法，一切就从这里开始了。
int mainint argc, char **argv) {
initServer);
aeCreateFileEventfd, acceptHandler, );
aeMain);
}
不要觉得我这里很复杂，其实主要就三大步。
第一步，我通过 listenToPort) 方法创建了一个 TCP 连接。
我的这个方法真是见名知意，而且如果展开看就更会发现没什么神秘的，就是 socket bind listen 标准三步走，建立了一个 TCP 监听，返回了一个文件描述符 fd。
第二步，我通过 aeCreateFileEvent) 方法，将上面那个创建了 TCP 连接返回的文件描述符 fd，加入到一个叫 aeFileEvent 的链表中。
同时将这个文件描述符绑定一个函数 acceptHandler，这样当有客户端连接进来时，便会执行这个函数。
第三步，我通过 aeMain) 方法，将上面的 aeFileEvent 链表中的文件描述符，统统作为 select 的入参，这是 IO 多路复用模式，如果不太了解的同学请阅读，《你管这破玩意叫 IO 多路复用？》。
好了，其实就是开启了一个 TCP 监听，然后如果有客户端进来的话，让他执行 acceptHandler 函数而已。
之后我就一直死等着客户端连接了。
void aeMainaeEventLoop *eventLoop)
{
eventLoop-stop = 0;
while !eventLoop-stop)
aeProcessEventseventLoop, AE_ALL_EVENTS);
}
不难想象，如果再来一个客户端，又来一个客户端… 那么不断将新客户端的文件描述符挂上去即可，而监听新客户端连接的，始终是最上面那个文件描述符。
好了，服务端开启了监听，客户端也连上了服务端，此时我仍然在死等状态，只不过等的不只是新客户端连接到达，还在等待已经连接上的客户端发来命令。
这里所谓的连接应答处理器，就是刚刚监听连接的文件描述符所绑定的函数 acceptHandler。
所谓的命令请求处理器，就是监听客户端命令（读事件）的文件描述符绑定的函数 readQueryFromClient。
所谓的命令回复处理器，就是后面要提到的，监听客户端响应（写事件）的文件描述符绑定的函数 sendReplyToClient。
这种一个负责响应 IO 事件，一个负责交给相应的事件处理器去处理，就叫做 Reactor 模式。
Redis 正是基于 Reactor 模式开发了自己的文件事件处理器，实现了高性能的网络通信模型，并且保持了 Redis 内部单线程设计的简单性。
有点担心这句话吹牛的逼格不够，其实我是参考了《Redis 设计与实现》，截图给大家。
具体怎么执行一个 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 分别存储起来。
处理完命令后，就要发送响应给客户端了。
static void setCommandredisClient *c) {
addReplyc, nx ? shared.cone : shared.ok);
}
这个响应，并不是直接同步写回去，当然也不是开启一个线程去异步写回去。
它仍然是调用那个万恶的 aeCreateFileEvent 函数，将 sendReplyToClient 函数挂在需要响应的客户端连接的文件描述符上。
static void addReplyredisClient *c, robj *obj) {
aeCreateFileEventserver.el, c-fd, AE_WRITABLE,
sendReplyToClient, c, NULL) == AE_ERR;
}
好了，这回上一小节挖的坑，终于补上了。
以上这些个破玩意，就是我的启动过程啦，我是不是很可爱。
后记
整篇文章我好像没讲 Redis 为啥那么快，因为我感觉这个问题问得不好。
你可以从接收网络请求的 IO 多路复用角度说起，也可以从事件处理器驱动的 Reactor 模式说起，还可以从具体处理命令时的数据结构说起，比如单单是字符串背后的 sds 其实就做了很多的巧妙设计。
如果我是面试官，我会具体让面试者聊聊 Redis 的启动流程，或者 Redis 处理命令的整个流程。
这里面可挖的点挺多的，如果能谈笑风生，那自然是技术水平还不错。
另外，你会发现本文出现的很多唬人的术语，比如 Reactor 模式，事件处理器等，看一遍 Redis 源码后你会发现真的非常简单。
毫不客气地说，一切丝毫不谈具体实现，和你堆砌一大堆唬人名词的文章或者人，都是在耍流氓。
本文我参考的是 Redis3.0.0 源码，但成文时用的讲解代码是 Redis1.0.0，整个网络模块的设计是完全一样的。