深入浅出redis事件框架

1) 事件驱动的常用数据结构

//eventLoop

typedef struct aeEventLoop {

    int maxfd;

    long long timeEventNextId;

    aeFileEvent events[AE_SETSIZE]; //注册的文件事件，注册事件数组默认10240长度，以fd为索引

    aeFiredEvent fired[AE_SETSIZE]; //发生的文件事件

    aeTimeEvent *timeEventHead; //时间事件链表

    int stop;

    void *apidata;//在linux 环境中对应aeApiState，依赖底层的epoll

    aeBeforeSleepProc *beforesleep;

} aeEventLoop;

//注册的文件事件

typedef struct aeFileEvent {

    int mask; /* one of AE_(READABLE|WRITABLE) */

    aeFileProc *rfileProc; //对应的读函数

    aeFileProc *wfileProc //对应的写函数;

    void *clientData; //

} aeFileEvent;

//发生的文件事件

typedef struct aeFiredEvent {

    int fd; //发生的事件对应的fd

    int mask;

} aeFiredEvent;

//时间事件（链表结构）

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 *next; //下一条时间事件

} aeTimeEvent;

//epoll的封装

typedef struct aeApiState {

    int epfd;

    struct epoll_event events[AE_SETSIZE];

} aeApiState;

见图:

2）常见场景

2.1） 启动 （redis.c：main)

2.1.1） 产生一个EventLoop（见ae.c:aeCreateEventLoop）

产生一个默认10240长度的注册事件数组，以fd为索引
产生关联的apistate对应epoll结构,事件容器(应用层)中的文件事件依赖epoll（系统层），即将epoll中的连接、读、写映射为事件

2.1.2）添加一个时间事件（见ae.c:aeCreateTimeEvent)

此时间事件1ms后触发
对应的回调函数是redis:serverCron
整个redis流程，就1处产生这个时间事件，其他就是redis benchmark

2.1.3）注册一个文件事件（见ae.c:aeCreateFileEvent）

注册一个监听事件到eventloop
同时将此事件注册到epoll
并将事件和networking.c:acceptTcpHandler函数绑定(此时server具有监听功能)

2.1.4) 进入无限轮询（见ae.c:：aeMain）

文件事件处理
确定网络阻塞的超时时间（timeout）
从时间事件链表中找到一个最近的时间事件,目的是为了确定接下来在处理文件事件中需要等待的时间
计算等待时间
如果存在最近时间使用最近的时间事件的时间-当前时间
如果不存在且如果设置了不用等待选项,等待时间为0，否则就是阻塞

从epoll中获取准备好的文件事件（连接、读、写）(见ae_epoll.c:aeApiPoll)
遍历准备好的文件事件，如果是可读，就调用用读函数，如果是可写就调用写函数

时间事件处理

启动完毕之后的状态见图：

2.2）文件事件处理（客户端发起连接-》客户端发请求-》服务端响应）

假设在启动时添加的文件事件fd为6，即服务器的监听套接字

2.2.1）客户端发起连接(./redis-cli)

在某次轮询中获取到事件（通过epoll感知到发生事件对应的fd为6，显然就是来了连接请求）
取出eventLoop中索引为6的文件事件，因为是读特性，于是调用对应的读函数（acceptTcpHandler）
在上面的处理函数中注册一个读事件到eventloop 
在eventLoop找到fd为7的文件事件(fd=6对应监听socket,fd=7对应连接socket)
将此fd注册到epoll
将此时间属性设为读事件
并将事件的读函数和networking.c:readQueryFromClient函数绑定

并将fd的网络设置即redisClient传递给该事件的clientData属性

此时连接已建立(新增),就等待客户端发请求了

状态见图：

2.2.2)客户端发请求（set foo bar）

和之前一样，从epoll感知来之fd为7的读事件，于是取出容器索引为7的文件事件，调用上面提到的readQueryFromClient
读取请求字节
解析请求字节（"*3\r\n$3\r\nset\r\n$3\r\nfoo\r\n$3\r\nbar\r\n"）
根据输入参数找到对应的命令函数
调用该函数进行处理
在上面的处理函数中注册一个写事件到eventloop 
在事件容器找到fd为7的文件事件
将此fd注册到epoll
将此事件属性设为读写事件

并将事件的写函数和networking.c:sendReplyToClient函数绑定
并将fd的网络设置即redisClient传递给该事件的clientData属性

状态见图

2.2.3) 服务端响应

一旦epoll感知到fd为7的写缓冲准备就绪，于是取出容器索引为7的文件事件，调用上面提到的sendReplyToClient
通过调整文件事件的mask注销写事件
通知epoll注销消息，不需要监听fd的写事件

状态如图：

2.2.4) 客户端关闭连接(ctrl+c)

epoll感知到读事件，此时网络状态为close_wait
调用上面提到的readQueryFromClient，从网络读取到EOF，于是调用freeClient关闭连接

状态如图：

2.3）时间事件(ae.c:processTimeEvents)

获取时间事件的头
确定本次需要处理的最大的时间事件id
循环时间事件链表，直到链表为空
如果时间事件的Id大于本次最大的id就掠过
如果时间事件的时间大于当前时间，则执行next
执行时间事件对应的处理函数
如果处理函数返回的不是-1，则修改该时间事件的时间（加上返回值），否则删除该事件，然后从头开始遍历

(系统唯一的servercron每次都会返回100ms)

3) 小结-redis为何如此高效？

从上面应该可以看到

事件框架实现了请求和I/O的解耦，请求过程一旦遇到IO，就注册到eventLoop,绝不等待，释放当前线程 
多路复用 epoll的使用
单线程无锁，无context切换
内存操作

但也有潜在的问题

单线程无法利用多核
cpu密集操作带来风险，一旦执行一些稍微耗时的命令，会阻塞其他命令执行
如果数据内容较大，比如value较大，超过内核的写缓存，会导致再次进入eventLoop才能处理，响应会有些延时