深入浅出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才能处理，响应会有些延时