为什么C/C++程序员都要阅读Redis源码之：Redis学习事件驱动设计
- 为什么我说C/C++程序员都要阅读redis源码
主要原因就是『简洁』。如果你用源码编译过Redis，你会发现十分轻快，一步到位。其他语言的开发者可能不会了解这种痛，作为C/C++程序员，如果你源码编译安装过Nginx/Grpc/Thrift/Boost等开源产品，你会发现有很多依赖，而依赖本身又有依赖，十分痛苦。通常半天一天就耗进去了。由衷地羡慕 npm/maven/pip/composer/...这些包管理器。而Redis则给人惊喜，一行make了此残生。
创新互联公司客户idc服务中心，提供郑州服务器托管、成都服务器、成都主机托管、成都双线服务器等业务的一站式服务。通过各地的服务中心，我们向成都用户提供优质廉价的产品以及开放、透明、稳定、高性价比的服务，资深网络工程师在机房提供7*24小时标准级技术保障。
除了安装过程简洁，代码也十分简洁。使用纯C语言编写，每个模块功能都划分的很清晰。
废话不多说，本文要介绍的是Redis里的事件处理功能，与Memcache引入libevent这一臃肿的事件库不同，Redis自己实现了一个小型轻量的事件驱动库——AE。阅读它的源码是一次非常好的学习和体验。
为什么C/C++程序员都要阅读Redis源码之：Redis学习事件驱动设计
- 跨平台兼容：重剑无锋，大巧不工
文件名说明ae.h/ae.c主要文件，根据OS平台的不同依赖以下不同文件：
ae_epoll.c：Linux平台
ae_kqueue.c：BSD平台
ae_evport.c：Solaris平台
ae_select.c：其他Unix平台
虽然源码文件看起来不少，但是实际上ae_epoll.c、 ae_kqueue.c、 ae_evport.c、 ae_select.c 这4个文件的功能是完全一样的，提供一致的API接口，给ae.c文件调用。这是由于实现高性能的事件驱动的API（称之为polling API）不存在ANSI或POSIX的标准，不同的OS内核有着自己的实现。比如Linux内核的epoll，BSD内核中的kqueue。
ae.c中有：
#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
这些HAVE的宏，都是由在config.h中定义的。依据不同的操作系统，引入这4个文件中的某一个。从功能上来说，这样设计的目的与GOF设计模式中“适配器模式”（修改成一致接口）或“外观模式”（抽象复杂接口为简单接口）的思想类似，但实际上我个人感觉更类似于《POSA》（卷二）中提到的“包装门面模式”（Wrapper Facade）。Anyway，这个编程思想值得学习。
为什么C/C++程序员都要阅读Redis源码之：Redis学习事件驱动设计
- 用C++去设计，用C编码：aeEventLoop
十几年前，以Linux之父炮轰C++为开端，社区内展开了一场C与C++孰是孰非的论战。而在国内，以原CSDN总编刘江援引此文为始，把战火烧到了国内。孟岩、云风、pongba几位大佬都身陷其中。后来以孟岩的一句『用C设计，用C++编码』在国内为这场论战定下基调。
反观Redis，他是纯C编码，但是融入了面向对象的思想。和上述观点截然相反，可谓是『用C++去设计，用C编码』。当然本文目的并非挑起语言之争，各种语言自有其利弊，开源项目的语言选择也主要是由于项目作者的个人经历和主观意愿。
定义在ae.h中的结构体 aeEventLoop 是AE库中最核心的数据结构，并且它采用了面向对象的设计思想：ae.h 中声明了多个函数，其第一个参数都是一个aeEventLoop指针，用于操纵aeEventLoop结构体。从这个角度来说，可以将该结构体理解为面向对象语言中的类，而操纵它的函数则可以视为其成员函数。（其实C++的class编译之后大概也是类似的模式）
aeCreateEventLoop：初始化一个事件循环结构体（eventLoop）
aeGetSetSize：返回当前setsize的值aeResizeSetSize改变setsize的值（空间重新分配）
aeDeleteEventLoop删除事件循环eventLoop（释放内存空间）
aeStop：停止事件循环，即stop值设为1
aeProcessEvents：核心部分：事件处理逻辑
aeMain：启动事件循环，事件循环的入口
aeSetBeforeSleepProc：注册回调函数，即每次主循环在休眠之前被调用
函数 aeCreateEventLoop 和 aeDeleteEventLoop 可以视为“类”aeEventLoop的构造和析构函数，其他为成员函数。
调用流程
在客户程序调用AE库的时候，一般是依次调用：
aeCreateEventLoop
aeSetBeforeSleepProc
aeMain
aeDeleteEventLoop
2.1 AE的两种事件
事件处理，是有别于多线程/多进程的并发模型。我也都知道Redis是单线程的。它的性能主要依靠异步事件处理功能来实现。虽然事件处理通常和网络编程混作一谈，但其实事件处理本身不一定是为网络编程服务的，它主要是服务于IO，网络通信是IO，文件读写同样是。当然Unix中万物皆文件了，socket也是一种fd。
AE支持两种事件：
文件事件（IO）时间事件（毫秒级）
这两种事件都作为aeEventLoop的结构体成员存在。
aeEventLoop各成员说明:
typedef struct aeEventLoop {
int maxfd; / 当前注册的最大fd /
int setsize; / 监视的fd的最大数量 /
long long timeEventNextId; / 下一个时间事件的ID /
time_t lastTime; / 上次时间事件处理时间 /
aeFileEvent events; / 已注册文件事件数组 /
aeFiredEvent fired; / 就绪的文件事件数组 /
aeTimeEvent timeEventHead; / 时间事件链表的头 /
int stop; / 是否停止（0：否；1：是）/
void apidata; / 各平台polling API所需的特定数据 /
aeBeforeSleepProc beforesleep; / 事件循环休眠开始的处理函数 /
aeBeforeSleepProc aftersleep; / 事件循环休眠结束的处理函数 /
} aeEventLoop;
文件事件，主要依靠两个数组。一个是注册的文件事件数组，一个是已就绪的文件事件数组。
typedef struct aeFileEvent {
int mask; / one of AE_(READABLE|WRITABLE|BARRIER) /
aeFileProc rfileProc;
aeFileProc wfileProc;
void *clientData;
} aeFileEvent;
typedef struct aeFiredEvent {
int fd;
int mask;
} aeFiredEvent;
单词Fired在这里表示的是就绪的意思，不知道是antirez英语不好，还是我英语不好，反正我是不知道fire有这层含义。
更新：经@Serena Yu提醒fire event是英语表示事件发出。果然还是我英语不好……
每个文件事件，其读写设置了不同的处理函数。另外mask表示事件的触发类型。当每次polling API返回就绪之后（比如epoll_wait返回），就绪会被设置到aeFireEvent，然后反查aeFileEvent获得处理函数并处理。你会发现aeFileEvent结构体里并没有记录fd。其实这是使用了HASH策略，aeEventLoop的成员 aeFileEvent数组的下标即是fd，便于快速查找。
时间事件，本质就是定时器任务，其数据结构采用一个双向链表。链表每个结点为aeTimeEvent结构体，主要包含事件的ID（递增）、就绪的时间，处理函数、清理函数、客户数据。
typedef struct aeTimeEvent {
long long id; / time event identifier. /
long when_sec; / seconds /
long when_ms; / milliseconds /
aeTimeProc timeProc;
aeEventFinalizerProc finalizerProc;
void clientData;
struct aeTimeEvent prev;
struct aeTimeEvent *next;
} aeTimeEvent;
每个事件循环中，每个时间事件的ID唯一且递增，主要依赖aeEventLoop里的timeEventNextId来维护这个ID的递增关系。创建新的时间事件时（aeCreateTimeEvent）会赋值，由于只考虑了单线程，所以没有加锁逻辑，大家也不要贸然把AE用在多线程环境中。另外创建时间过程就是简单的追加到时间事件链表的尾部，并没有针对就绪时间做排序。
when_sec和 when_ms 记录了时间事件的就绪时间（秒+毫秒），即当当前时间大于等于这个时间的时候，该时间事件应被处理。
时间事件的处理过程（processTimeEvents）主要就是：继续遍历链表，如果发现节点状态为AE_DELETED_EVENT_ID则删除该节点。如果判断当前时间已经超过节点的就绪时间就开始处理。处理函数的返回值可以指定，后续不再处理该事件（NOMORE），则该节点会被置为AE_DELETED_EVENT_ID。如果下次还需要处理，则更新该节点的时间为下次就绪时间。
为什么C/C++程序员都要阅读Redis源码之：Redis学习事件驱动设计
2.2 事件循环的处理逻辑
再用一张图，回顾一下EventLoop中的两种事件，基本可以做如下理解。一个链表，一个数组。文件事件中的数组不是线性填满的，因为是采用的HASH策略，将fd作为数组下标了。
为什么C/C++程序员都要阅读Redis源码之：Redis学习事件驱动设计
aeProcessEvents是aeEventLoop在循环过程中的的实际处理逻辑。
aeProcessEvents 是aeEventLoop在循环过程中的的实际处理逻辑。函数原型如下：
int aeProcessEvents(aeEventLoop *eventLoop, int flags);
flags标记，表示本次需要处理的事件类型标记和是否阻塞标记。
AE_TIME_EVENTS：时间事件标记
AE_FILE_EVENTS：文件事件标记
AE_DONT_WAIT：立即返回不阻塞等待的标记
aeProcessEvents代码我就不贴了。它巧妙的地方是一次柔和了文件和时间事件的两种处理过程。
在函数之初，会线性查找时间事件的链表，找到最近时间内会就绪时间事件，然后用它的就绪时间减去当前时间的时间差作为polling API的休眠时间（epoll_wait的timeout参数）。然后休眠等待polling api返回。在返回之后先执行aftersleep的的处理逻辑，然后执行这段休眠时间内就绪的文件事件，最后再处理就绪的时间事件。返回值是处理过的事件总数。
也就说AE会尽量在一次处理过程中，将时间事件和文件事件一次性处理。你也许会问如果没有时间事件怎么办。当然没关系，在aeProcessEvents开始部分就根据标记位进行了判断。上面的逻辑是在文件事件和时间事件都存在的情况下，如果仅存在文件事件，则看是否设置了不阻塞的标记（AE_DONT_WAIT），若有，则polling 的超时时间设置为0。如无，即可以阻塞，则设置为-1，则polling API会阻塞直到有文件事件发生。
纵观AE是一种非常简易但也十分典型的Reactor网络模型。
ae_epoll（Linux上polling API：epoll的封装）
前文说道Redis适配各种Unix-like的操作系统。它将系统强相关的事件API部分单独抽出来，包装出了相同的接口给AE的对外API调用。在Linux系统上的API实现为：ae_epoll.c，建议在阅读这个文件源码之前先好好回顾一下epoll的API，这样更助于快速理解。相信工作后大家写业务逻辑，应该很少接触epoll了。可以阅读这个wik，快速回顾epoll的api：LinuxAPI：epoll
ae_epoll.c 完全被 ae.c调用。各函数调用关系如下(aeApi开头的都是ae_epoll.c中的函数)：
ae.c
aeCreateEventLoop
aeApiCreate
aeResizeSetSize
aeApiResize
aeDeleteEventLoop
aeApiFree
aeCreateFileEvent
aeApiAddEvent
aeDeleteFileEvent
aeApiDelEvent
aeProcessEvent
aeApiPoll
aeGetApiName
aeApiName
除了aeApiName()以外，其他函数第一个参数也都是aeEventLoop * 。用面向对象的思想来看这也是aeEventLoop的成员函数。试想若是C++，则可能会被处理成父子两个类，而aeApi系列的函数是纯虚的。
aeApi的函数也是可以做到顾名即可思义。比如：
aeApiCreate在堆上进行内存的分配，封装epoll_create创建epfd，并写入aeEventLoop。
aeApiAddEvent、aeApiDelEvent是封装的epoll_ctl来对aeEventLoop的监控的epoll事件进行添加和删除。
aeApiPoll是封装的epoll_wait开启事件循环，并且每次取出就绪的fd存入aeEventLoop的fired数组中，并置位相应的mask（读or写）
aeApiResize、aeApiFree分别进行的是内存的重分配、资源的清理（关闭epfd，free内存）和epoll本身关联不大。
不止AE中，整个Redis在使用堆内存的时候，都是使用它自己实现的zmalloc，而非libc的malloc。
Jim：吃水不忘挖井人，AE的灵感之源
阅读完AE代码，可能只需要一下午的时间，你会惊叹于作者的设计功力。其实里面也没有太多花哨的东西，但就是如此简洁清晰的给你呈现了一个完成度如此之高的事件驱动处理库。但我想即使大家都熟悉epoll、熟悉kqueue、熟悉数据结构也不一定能设计出来AE，所以把程序员比作代码的设计师、建筑师是丝毫不为过的。
“吃水不忘挖井人”，AE的设计灵感也是受另外一个开源项目影响，它就是 Jim。Redis的ae.c的开篇注释中就已注明：
/* A simple event-driven programming library. Originally I wrote this code
- for the Jim's event-loop (Jim is a Tcl interpreter) but later translated
- it in form of a library for easy reuse.
Jim的源码在Github上有它的镜像，其中事件循环的代码在此：https://github.com/msteveb/jimtcl/blob/master/jim-eventloop.c
简单阅读一下，你就会发现AE确实整体的处理逻辑是从Jim吸收的。但AE也不乏创新，比如抽象除polling API这层，达到了多平台的兼容和解耦，而Jim强耦合了select。
Anyway，就像经典的『站在巨人肩膀』理论，虽然Jim不是巨人，但它启发了AE，即使Jim最终被世人遗忘，而它的血肉也化作了土壤，滋养后来人，这就是开源运动的意义所在，也是魅力所在。
本文标题：为什么C/C++程序员都要阅读Redis源码之：Redis学习事件驱动设计
文章转载：http://mswzjz.cn/article/jscgeo.html