深入浅出redis事件框架

woceshiyong8

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