深入浅出redis事件框架
1) 事件驱动的常用数据结构
//eventLoop
typedef struct aeEventLoop {
int maxfd;
long long timeEventNextId;
aeFileEvent events; //注册的文件事件，注册事件数组默认10240长度，以fd为索引
aeFiredEvent fired; //发生的文件事件
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;
} aeApiState;
见图:
http://files.note.sdo.com/CQ4G7~jJY0vgLX0xk0003A
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)
[*]遍历准备好的文件事件，如果是可读，就调用用读函数，如果是可写就调用写函数
[*]时间事件处理
启动完毕之后的状态见图：
http://files.note.sdo.com/CQ4G7~jJY3d9nM03w0003H
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属性
[*]此时连接已建立(新增),就等待客户端发请求了
状态见图：
http://files.note.sdo.com/CQ4G7~jJY3t9nM03w0003O
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属性
状态见图
http://files.note.sdo.com/CQ4G7~jJY3WpnM03w00044
2.2.3) 服务端响应
[*]一旦epoll感知到fd为7的写缓冲准备就绪，于是取出容器索引为7的文件事件，调用上面提到的sendReplyToClient
[*]通过调整文件事件的mask注销写事件
[*]通知epoll注销消息，不需要监听fd的写事件
状态如图：
http://files.note.sdo.com/CQ4G7~jJY47VnM03w0004a
2.2.4) 客户端关闭连接(ctrl+c)
[*]epoll感知到读事件，此时网络状态为close_wait
[*]调用上面提到的readQueryFromClient，从网络读取到EOF，于是调用freeClient关闭连接
状态如图：
http://files.note.sdo.com/CQ4G7~jJY4i9nM03w0004k
2.3）时间事件(ae.c:processTimeEvents)
[*]获取时间事件的头
[*]确定本次需要处理的最大的时间事件id
[*]循环时间事件链表，直到链表为空
[*]如果时间事件的Id大于本次最大的id就掠过
[*]如果时间事件的时间大于当前时间，则执行next
[*]执行时间事件对应的处理函数
[*]如果处理函数返回的不是-1，则修改该时间事件的时间（加上返回值），否则删除该事件，然后从头开始遍历
(系统唯一的servercron每次都会返回100ms)
3) 小结-redis为何如此高效？
从上面应该可以看到
[*]事件框架实现了请求和I/O的解耦，请求过程一旦遇到IO，就注册到eventLoop,绝不等待，释放当前线程
[*]多路复用 epoll的使用
[*]单线程无锁，无context切换
[*]内存操作
但也有潜在的问题
[*]单线程无法利用多核
[*]cpu密集操作带来风险，一旦执行一些稍微耗时的命令，会阻塞其他命令执行
[*]如果数据内容较大，比如value较大，超过内核的写缓存，会导致再次进入eventLoop才能处理，响应会有些延时
页:
[1]