如何深入探究Redis命令处理机制源码的编写原理？

今天来讲讲 Redis 的请求监听，通俗点说，就是Redis是如何监听客户端发出的set、get等命令的。 基础架构 众所周知，Redis 是单进程单线程架构，虽然是单进程单线程，但是Redis的性能却毫不逊色，能轻松应对一般的高并发场景，那么Redis究竟是施了什么魔法呢？ 其实 Redis 的原理和 Nginx 差不多，都利用了IO 多路复用来提高处理能力，所谓多路复用，就是一个线程可以同时处理多个IO操作，当 某个 IO 操作 Ready 时，操作系统会主动通知进程。使用 IO 多路复用，我们可以使用 epoll、kqueue、select，API 都差不多。 与Redis 不同的是，Nginx 并不是单进程架构，而是采用了多进程来处理请求。Nginx跑起来后会先启动Master进程，Master进程接着启动多个 Worker 进程，每个Worker 进程都会参与请求的监听和处理。这样可以充分发挥CPU的多核特性。 虽然 Redis 是单进程单线程，不能利用多核，但同样也避免了多进程的并发问题，也就没有了锁带来的开销。 源码探究 Redis 入口是 server.c 中的 main（）方法，main（）中会调用 initServer（）初始化 Redis 服务。 初始化 Redis 服务 Redis 为了进行事件监听，特地封装了一个struct：aeEventLoop，定义在 ae.c 中。 为什么需要 aeEventLoop 呢？因为 Redis 针对于 epoll、evport、select 还有 kqueue 的 API做了封装，分别为 ae_epoll、ae_evport、ae_select 和 ae_kqueue。但是 Redis 在使用监听的时候，统一调用的都是 aeEventLoop 中的方法。ae.c 在预处理阶段使用了条件编译，这样便可以选择平台支持的 API 来使用多路复用。 #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 这里Redis 选择了 Mac 平台支持的 kqueue 使用多路复用，所以后面源码分析的时候，我都会基于 kqueue 来讲解。 创建内核事件队列 initServer（）第一件做的事情就是为当前服务创建了一个 aeEventLoop，后续的所有命令监听，都是基于 aeEventLoop 来做的。 server.el = aeCreateEventLoop(server.maxclients+CONFIG_FDSET_INCR); aeCreateEventLoop（）内部会调用 aeApiCreate（），选择性的调用epoll、select 或者 kqueue 的 API，创建事件监听。这里拿 kqueue 来举例子，我们可以看下 ae_kqueue.c 中的实现。 static int aeApiCreate(aeEventLoop *eventLoop) { aeApiState *state = zmalloc(sizeof(aeApiState)); ...... state->events = zmalloc(sizeof(struct kevent)*eventLoop->setsize); state->kqfd = kqueue(); ...... eventLoop->apidata = state; return 0; } 上面创建了一个 aeApiState，并且调用了 kqueue 的API：kqueue（）： // 创建一个内核消息队列，返回队列描述符 int kqueue(void); 这里创建了一个内核事件队列，并将该队列的文件描述符存入了 state->kqfd 中。