2.1.2事件驱动reactor的原理与实现

简介: 2.1.2事件驱动reactor的原理与实现

先来了解一下epoll

select(maxfd, rfds, wfds, efds, timeout);
poll(pfds, length, timeout);
#include <sys/epoll.h>
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

对比三种IO多路复用调用,可以发现,epoll有三个系统调用。

epoll把用户关心的文件描述符上的事件放在内核的一个事件表中,通过epoll_create返回一个文件描述符epollfd,该描述符用来唯一标识内核中的这个事件表。epoll_create中的size参数无关紧要,但要给一个大于0的值,这是一个历史遗留问题,来看一下man手册中的介绍:

为了兼容,这里传入一个大于0的值。

epoll_ctl第一个参数传入epollfdop表示操作类型,fd是要操作的文件描述符,event是事件类型。

操作类型op有3种:

EPOLL_CTL_ADD 往事件表中注册fd上的事件
EPOLL_CTL_MOD 修改fd上的注册事件
EPOLL_CTL_DEL 删除fd上的注册事件

epoll_event的定义:

The struct epoll_event is defined as :
typedef union epoll_data {
    void    *ptr;
    int      fd;
    uint32_t u32;
    uint64_t u64;
} epoll_data_t;
struct epoll_event {
    uint32_t     events;    /* Epoll events */
    epoll_data_t data;      /* User data variable */
};

epoll_event中的events用来描述事件类型,epoll支持的事件类型和poll基本相同。表示epoll事件类型的宏是在poll对应的宏前加上“E”,比如epoll的数据可读事件是EPOLLIN。data用来存放用户数据,epoll_data_tfd可以存放用户fdptr用来指定与fd相关的用户数据,但由于epoll_data是一个联合体,所以不能同时使用ptrfd,因此我们可以在ptr指向的用户数据中包含fd

epoll_wait在一段超时时间内等待一组文件描述符上的事件,函数成功时返回就绪的文件描述符的个数。events是传出参数,epoll_wait函数如果检测到事件,就将所有就绪的事件从内核事件表中复制到它的第二个参数events指向的数组中。这个数组只用于输出epoll_wait检测到的就绪事件,因此,当epoll_wait返回时,我们只需要遍历这个数组就好了,大大提高了效率。

来看一下pollepoll的区别:

int ret = poll(fds, MAX_EVENT_NUMBER, -1);
//遍历所有sockfd
for (int i = 0; i < MAX_EVENT_NUMBER; i++) {
    if (fds[i].revents & POLLIN) {
        int sockfd = fds[i].fd;
        //处理事件
    }
}
int ret = epoll_wait(epollfd, events, MAX_EVENT_NUMBER, -1);
//遍历就绪sockfd
for (int i = 0; i < ret; i++) {
    int sockfd = events[i].data.fd;
    //处理事件
}

让我们改写一下之前的例子:

#include <sys/epoll.h>
...
  int clientfd = 0;
    int epfd = epoll_create(1);
    struct epoll_event ev;
    ev.events = EPOLLIN;
    ev.data.fd = sockfd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &ev);
    struct epoll_event events[1024] = {0};
    while (1) {
        int nready = epoll_wait(epfd, events, 1024, -1);
        if (nready < 0) continue;
        int i = 0; 
        for (i = 0; i < nready; i++) {
            int connfd = events[i].data.fd;
            if (sockfd == connfd) {
                clientfd = accept(sockfd, (struct sockaddr*)&clientaddr, &len);
                if (clientfd < 0) {
                    continue;
                }
                printf("clientfd: %d\n", clientfd);
                ev.events = EPOLLIN;
                ev.data.fd = clientfd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
            } else if (events[i].events & EPOLLIN) {
                char buffer[BUFFER_LENGTH] = {0};
                int n = recv(connfd, buffer, BUFFER_LENGTH, 0);
                if (n > 0) {
                    printf("recv : %s\n", buffer);
                    send(connfd, buffer, n, 0);
                } else if (n == 0) {
                    printf("close\n");
                    epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
                    close(connfd);
                }
            }
        }
    }
...

运行程序发现,这个程序也可以支持多个客户端连接并发送数据。

epoll比较高效的原因还有一个是它对文件描述符的操作有两种模式:LT(水平触发)和ET(边缘触发)。selectpoll都只能工作在相对低效的LT模式。epoll默认是水平触发,这种模式下epoll相当于一个效率较高的poll。当往epoll内核事件表中注册一个文件描述符上的EPOLLET事件时,epoll将以ET模式来操作该文件描述符。ET模式是epoll的高效工作模式。

对于采用LT工作模式的文件描述符,当epoll_wait检测到其上有事件发生并将此事件通知应用程序后,应用程序可以不立即处理该事件。这样,当应用程序下一次调用epoll_wait时,epoll_wait还会再次向应用程序通告此事件,直到该事件被处理。而对于采用ET工作模式的文件描述符,当epoll_wait检测到其上有事件发生并将此事件通知应用程序后,应用程序必须立即处理该事件,因为后续的epoll_wait调用将不再向应用程序通知这一事件。可见,ET模式在很大程度上降低了同一个epoll事件被重复触发的次数,因此效率要比LT模式高。

关于水平触发和边缘触发在我脑海中一直有一个电信号的图:

水平触发在于看当前状态,比如当前状态是高电平就会一直触发,而边沿触发在于看状态变化,比如从低电平变为高电平,这个过程只会触发一次,想要再次触发,只能状态发生改变。

让我们来验证一下,epoll默认是水平触发方式,我们把接收缓存区改小,发送的数据长度大于接收缓存区,这样,一次接收不完,事件会一直触发,直到把所有的数据都接收完:

...
      } else if (events[i].events & EPOLLIN) {
                char buffer[10] = {0};
                int n = recv(connfd, buffer, 10, 0);
                if (n > 0) {
...

连接发送“http://www.cmsoft.cn QQ:10865600”

输出显示:

clientfd: 5
recv : http://www
recv : .cmsoft.cn
recv :  QQ:108656
recv : 00

而如果我们在添加事件时加上边缘触发,recv则只调用一次:

printf("clientfd: %d\n", clientfd);
        //here
                ev.events = EPOLLIN | EPOLLET;
                ev.data.fd = clientfd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
            } else if (events[i].events & EPOLLIN) {
                char buffer[10] = {0};
                int n = recv(connfd, buffer, 10, 0);
                if (n > 0) {
                    printf("recv : %s\n", buffer);
                    send(connfd, buffer, n, 0);

输出:

clientfd: 5
recv : http://www

并且再次触发事件后,recv会接着处理上次没接收完的数据!

所以,ET模式效率高的原因就在于同一事件(比如可读或可写事件)只会触发一次,而LT只要状态不变就会一直触发。同时这也引出了一个问题,对于ET模式,当有事件来时,就要一次把这个事件处理完,因为之后不会再触发该事件,即使上一次该事件没处理完。

以上便是epoll相关的内容,epoll是对IO的管理,接下来的reactor则是对事件的管理。

文章参考与<零声教育>的C/C++linux服务期高级架构系统教程学习:https://ke.qq.com/course/417774?flowToken=1020253

相关文章
|
4月前
|
消息中间件 Kubernetes NoSQL
Reactor 和 Proactor 区别
Reactor 和 Proactor 区别
|
7月前
|
缓存 网络协议 Dubbo
异步编程 - 12 异步、基于事件驱动的网络编程框架 Netty
异步编程 - 12 异步、基于事件驱动的网络编程框架 Netty
46 0
|
4月前
|
监控 安全 Linux
reactor的原理与实现
前情回顾 网络IO,会涉及到两个系统对象:   一个是用户空间调用的进程或线程   一个是内核空间的内核系统 如果发生IO操作read时,会奖励两个阶段:
36 1
|
4月前
|
API Windows
Reactor和Proactor网络模型的区别
Reactor和Proactor网络模型的区别
|
5月前
|
监控 Java 应用服务中间件
Reactor反应器模式
在Java的OIO编程中,最初和最原始的网络服务器程序使用一个while循环,不断地监听端口是否有新的连接,如果有就调用一个处理函数来处理。这种方法最大的问题就是如果前一个网络连接的处理没有结束,那么后面的连接请求没法被接收,于是后面的请求统统会被阻塞住,服务器的吞吐量就太低了。 为了解决这个严重的连接阻塞问题,出现了一个即为经典模式:Connection Per Thread。即对于每一个新的网络连接都分配一个线程,每个线程都独自处理自己负责的输入和输出,任何socket连接的输入和输出处理不会阻塞到后面新socket连接的监听和建立。早期版本的Tomcat服务器就是这样实现的。
|
6月前
|
存储 索引
2.2 事件驱动的reactor网络设计模型
2.2 事件驱动的reactor网络设计模型
20 0
|
10月前
|
网络协议 数据处理
Reactor模式(二)
Reactor模式
54 0
|
10月前
|
设计模式 网络协议 数据处理
Reactor模式(一)
Reactor模式
67 0
|
10月前
|
Java 数据库
基于 Reactor 的响应式编程应用场景
基于 Reactor 的响应式编程应用场景
114 0
|
监控 NoSQL Java
Netty高性能架构之Reactor模式
在讨论Netty的架构模式之前,我们先来介绍下Reactor模式,因为Netty的架构模式是在此基础上演变而来的
Netty高性能架构之Reactor模式