Redis事件驱动

结合服务器端与客户端的交互，先讲清楚epoll这种异步I/O机制。

服务器与客户端都是通过网络套接字socket进行通信的。

socket在liunx中可以理解为一个文件。

文件，i/o函数都是针对文件描述符的。打开一个文件，返回一个文件描述符，然后使用该文件描述符进行后续的i/o操作。

最常见的I/O操作是系统调用read&write，read把数据从内核缓冲区读出；write把数据写入内核缓冲区。

服务器端与客户端调用socket后，就可以用用返回的文件描述符去调用内核缓冲区的数据。如下图：

以server内核缓冲区为例来做说明：

1.初始化server内核缓冲区为空。这时 serverfd.read()去读数据，无数据server被阻塞。

2.clifd.write()往server内核缓冲区中写入数据，就会产生一个数据非空的事件，这个事件去唤醒server。

3.假设server没有取出流中的数据。server内核缓冲区写满，此时cli就会被阻塞。

4.此时serverfd.read()来读取数据，产生一个数据非满的事件，这个事件去唤醒cli。

以上是一种阻塞I/O模式下，很明显，无论对于server或者是cli，他们都只能处理一个缓冲区中的数据。

如果要处理多个缓冲区的数据，只能考虑多进程或者是多线程。开销大，并且效率不高。

（明明不阻塞就可以处理，却阻塞创建新进程来处理）

所以现在考虑非阻塞I/O模式。

最简单的就是轮询所有的文件描述符，就可以处理所有的事件了。

while true

 {

    for i in fds[]; {

        if i has data

            read until unavailable

    }

}

上面相当于去做一个忙轮询，cpu不间断做轮询。如果所有的流都没有发生任何事件，此时cpu就处于空转状态。

为了避免cpu空转的现象，我们引入一个代理比如select 、epoll。实现以下功能：

1.实现对所有注册过的文件描述符进行监控。一旦该进程发现数据非空或者非满的事件，返回相关信息给调用该代理的主进程，由主进程调用相关进程做响应；

2.空闲的时候，将当前进程阻塞。

比如：

1.监控事件：

clifd(客户端文件描述符)，serverfd(服务器文件描述符)注册到代理中。

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

初始化server内核缓冲区为空，server此时并不会去读（即使去读，设置为非阻塞也不会被阻塞，就可以做一些其他的操作），

直到clifd.write()往内核缓冲区中写数据，触发缓冲区非空事件。被轮询的代理捕捉到这个事件，返回给主进程，主进程调用serverfd.read()才会去读数据。

2.阻塞：

当代理未返回任何事件时候，调用它的主进程可被阻塞。

 int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

其中timeout可设置主进程被阻塞的时间。

到这里我们讲清楚，为了高效的处理i/o事件，引入了像select、epoll这样的i/o异步处理机制。

epoll与select机制的优势：

1.select仅仅告知我们有i/o事件发生。是哪个描述符发生，以及发生了什么样的i/o事件。需要我们无差别的轮询所有的文件描述符。

2.epoll同时返回描述符和发生的i/o事件。

epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。

1. int epoll_create(int size);

创建一个epoll的句柄。自从linux2.6.8之后，size参数是被忽略的。需要注意的是，当创建好epoll句柄后，它就是会占用一个fd值，在linux下如果查看/proc/进程id/fd/，是能够看到这个fd的，所以在使用完epoll后，必须调用close()关闭，否则可能导致fd被耗尽。

 

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件注册函数，它不同于select()是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

第一个参数是epoll_create()的返回值。

第二个参数表示动作，用三个宏来表示：

EPOLL_CTL_ADD：注册新的fd到epfd中；

EPOLL_CTL_MOD：修改已经注册的fd的监听事件；

EPOLL_CTL_DEL：从epfd中删除一个fd；

第三个参数是需要监听的fd。

第四个参数是告诉内核需要监听什么事，struct epoll_event结构如下：

[cpp] view plaincopyprint?

1. //保存触发事件的某个文件描述符相关的数据（与具体使用方式有关）  
2.   
3. typedef union epoll_data {  
4.     void *ptr;  
5.     int fd;  
6.     __uint32_t u32;  
7.     __uint64_t u64;  
8. } epoll_data_t;  
9.  //感兴趣的事件和被触发的事件  
10. struct epoll_event {  
11.     __uint32_t events; /* Epoll events */  
12.     epoll_data_t data; /* User data variable */  
13. };  

events可以是以下几个宏的集合：可以读（包括对端SOCKET正常关闭）；

EPOLLOUT：表示对应的文件描述符标识的文件流可以写；缓冲区可以写。 注意这是个标识

EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；

EPOLLERR：表示对应的文件描述符发生错误；

EPOLLHUP：表示对应的文件描述符被挂断；

EPOLLET： 将EPOLL设为边缘触发(Edge Triggered)模式，这是相对于水平触发(Level Triggered)来说的。

EPOLLIN ：表示对应的文件描述符  缓冲区可读

EPOLLONESHOT：只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

收集在epoll监控的事件中已经发送的事件。参数events是分配好的epoll_event结构体数组，epoll将会把发生的事件赋值到events数组中（events不可以是空指针，内核只负责把数据复制到这个events数组中，不会去帮助我们在用户态中分配内存）。maxevents告之内核这个events有多大，这个 maxevents的值不能大于创建epoll_create()时的size，参数timeout是超时时间（毫秒，0会立即返回，-1将不确定，也有说法说是永久阻塞）。如果函数调用成功，返回对应I/O上已准备好的文件描述符数目，如返回0表示已超时。

事件驱动的定义：在持续事物管理的过程中，进行决策的一种策略，即跟随当前时间点出现的事件，调用可用资源，使不断出现的问题得以解决，防止事物堆积，防止事物堆积。

Redis事件数据结构图：

aeFileEvent-----文件事件结构体：

在Redis事件驱动中，文件事件是由i/o异步机制实现的。

Redis支持epoll、select、kqueue、以及基于Solaris的event ports。

以下讲解都是基于epoll这种i/o异步机制。

注册epoll的三要素：1.文件描述符 2.事件标识（读事件/写事件） 3.触发之后的回调函数

typedef struct aeFileEvent {
    int mask; /* one of AE_(READABLE|WRITABLE) */

    aeFileProc *rfileProc;  //指向触发读事件之后的回调函数
    aeFileProc *wfileProc; //指向触发写事件之后的回调函数
    void *clientData;       //初始化为空 
} aeFileEvent;

aeFiredEvent-------已经触发的文件事件

typedef struct aeFiredEvent {
     int fd;      //文件描述符
     int mask; //事件标识（读事件/写事件）
 } aeFiredEvent;

aeApiState-------未封装的已触发的事件

typedef struct aeApiState {
    int epfd;    //epoll文件描述符
    struct epoll_event events[AE_SETSIZE];  //epoll_wait返回的触发事件数组,包含文件描述符以及触发事件。
} aeApiState;

aeTimeEvent------时间事件结构体：

时间事件是一个链表结构，所有的时间事件依次执行。

我们是基于Redis2.4这个版本做的改造，只有一个循环时间事serverCron。

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;

aeEventLoop------ State of an event based program

/* State of an event based program */
typedef struct aeEventLoop {
    int maxfd;    //最大的fd的数量   redis定义的为1024 也就是能够同时监听1024个fd 
    long long timeEventNextId;   //时间事件的下一个id
    aeFileEvent events[AE_SETSIZE]; /* Registered events */
    aeFiredEvent fired[AE_SETSIZE]; /* Fired events */
    aeTimeEvent *timeEventHead;   //时间事件的头结点
    int stop;   //退出事件循环的标识  
    void *apidata; /* This is used for polling API specific data */   //指向一个aeApistate的结构体 这个结构体包含两方面的信息  epfd 另外一个为空
    aeBeforeSleepProc *beforesleep;  //在进入时间事件之前所执行的函数
} aeEventLoop;

下面进行Redis整个事件机制驱动的说明：

各种文章已经说的很清楚了，懒得赘述。列一篇：

http://mp.weixin.qq.com/s?__biz=MjM5MDg2NjIyMA==&mid=202350583&idx=1&sn=bf6955682aa222c3326323642792a7bf#rd

千言万语都在图中（sina微盘 http://vdisk.weibo.com/s/z9No9RlErvEAi/1417080830）。

图中主要是以客户端和服务器端的交互来说明文件事件驱动。

在redis中唯一的时间事件是一个定时事件，没有展开画（太大）。

时间事件的触发机制很简单，就是轮询的过程中，定时触发。