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才能处理,响应会有些延时