- epoll-reactor模型原理即代码解析
- epoll
- Reactor服务器模型
网络IO *** 作一般会涉及两个系统对象，一个是用户空间调用 IO 的进程或者线程，另一个是内核空间的内核系统，比如发生 IO *** 作 read 时，它会经历两个阶段：
-
等待数据准备就绪
-
将数据从内核拷贝到进程或者线程中。
不同情况地处理这两个阶段上，可以分为不同的服务器模型，最常用的如Reactor 与 Proactor ，本文主要记录自己对epoll到reactor模型的演变及分析。
下面是利用epoll多路复用和非阻塞IO+ET边缘触发设计的并发服务器程序：（详细了epoll原理分析可查看该文章链接: link.）
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MAXLNE 4096
#define EPOLL_SIZE 1024
int main() {
int listenfd, connfd, n;
struct sockaddr_in servaddr;
char buff[MAXLNE];
if ((listenfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
printf("create socket error: %s(errno: %d)\n", strerror(errno), errno);
return 0;
}
memset(&servaddr, 0, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(10000);
if (bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1) {
printf("bind socket error: %s(errno: %d)\n", strerror(errno), errno);
return 0;
}
if (listen(listenfd, 10) == -1) {
printf("listen socket error: %s(errno: %d)\n", strerror(errno), errno);
return 0;
}
int epfd = epoll_create(1);
struct epoll_event events[EPOLL_SIZE] = {0};
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = listenfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);
while(1) {
int nready = epoll_wait(epfd, events, EPOLL_SIZE, 5);//nready是返回的监控文件描述符中有响应的描述符个数
if(nready == -1) {
continue;
}
for(int i = 0; i < nready; i++) {
int clientfd = events[i].data.fd;
if(clientfd == listenfd) {
struct sockaddr_in client;
socklen_t len = sizeof(client);
if((connfd = accept(listenfd, (struct sockaddr *)&client, &len)) == -1) {
printf("accept socket error: %s(errno: %d)\n", strerror(errno), errno);
return 0;
}
printf("accept Success fd= %d\n", connfd);
int flag = 0;
if ((flag = fcntl(clientfd, F_SETFL, O_NONBLOCK)) < 0) {//设置与客户端通信的socket为非阻塞
printf(" fcntl nonblocking failed\n");
break;
}
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = connfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);
}
else if(events[i].events & EPOLLIN) {
n = recv(clientfd, buff, MAXLNE, 0);//因为使用的ET模式，这里其实最好使用while循环将fd的数据全部读到buff中（防止数据多一次读不完的情况）
if (n > 0) {
buff[n] = '\0';
printf("recv msg from client: %s\n", buff);
ev.events = EPOLLOUT;//注册EPOLLOUT事件，让服务器发送数据
ev.data.fd = clientfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
}
else if (n == 0) {//当客户端调用close时，会返回n=0
ev.events = EPOLLIN;
ev.data.fd = clientfd;
epoll_ctl(epfd, EPOLL_CTL_DEL, clientfd, &ev);//删除EPOLL事件
close(clientfd);
}
}else if(events[i].events & EPOLLOUT) {
send(clientfd, buff, n, 0);//将发送来的数据依次返回发送回去
ev.events = EPOLLIN | EPOLLET;//重新注册EPOLL事件
ev.data.fd = clientfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, clientfd, &ev);
}
}
}
return 0;
}
epoll监控事件描述图：
Reactor服务器模型epoll的Reactor模型监控事件描述图：
从图中可以看出，reactor多了一个结构体。
服务进程处理epoll事件也不是单纯的逻辑 *** 作，而是通过对应的事件数组中事件对应的fd指向的回调函数来处理接下来的逻辑 *** 作。
回想一下普通函数调用的机制：程序调用某函数，函数执行，程序等待，函数将结果和控制权返回给程序，程序继续处理。
Reactor 释义“反应堆”，是一种事件驱动机制。
和普通函数调用的不同之处在于：应用程序不是主动的调用某个 API 完成处理，而是恰恰相反，Reactor 逆置了事件处理流程(不再是主动地等事件就绪，而是它提前注册好的回调函数，当有对应事件发生时就调用回调函数)，应用程序需要提供相应的接口并注册到 Reactor 上，如果相应的事件发生，Reactor 将主动调用应用程序注册的接口，这些接口又称为“回调函
数”。
Reactor程序如下：
#include 从程序可以看出
= len send (,fd, ev->buffer, ev->length0 );//发送数据if
( 0len > )printf {
("send[fd=%d], [%d]%s\n",, fd, len) ev->buffer;nty_event_del
(,reactor->epfd) ev;//删除epoll注册事件nty_event_set
(,ev, fd, recv_cb) reactor;//设置回调函数nty_event_add
(,reactor->epfd| EPOLLIN , EPOLLET) ev;//条件epoll注册事件响应快，不必为单个同步事件所阻塞，虽然 Reactor 本身依然是同步的；
发送完数据就删除epoll注册事件，再重新注册。
如此频繁的增加删除是否浪费CPU资源？
答：对于同一个socket而言，完成收发至少占用两个树上的位置（不删除的情况）。
而交替（本文情况）只需要一个。
因此从这个角度看增加删除 *** 作epoll事件不会更加浪费CPU资源。
Reactor 模式是编写高性能网络服务器的必备技术之一，它具有如下的优点：
- 编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
- 可扩展性，可以方便的通过增加 Reactor 实例个数来充分利用 CPU 资源；
- 可复用性，reactor 框架本身与具体事件处理逻辑无关，具有很高的复用性；
Reactor 模型开发效率上比起直接使用 IO 复用要高，它通常是单线程的，设计目标是希望单线程使用一颗 CPU 的全部资源，但也有附带优点，即每个事件处理中很多时候可以不考虑共享资源的互斥访问。
可是缺点也是明显的，现在的硬件发展，已经不再遵循摩尔定律，CPU 的频率受制于材料的限制不再有大的提升，而改为是从核数的增加上提升能力，当程序需要使用多核资源时，Reactor 模型就会悲剧。
网络服务器中还有个Proactor模型也比较流行， proactor 模型最大的特点就是 Proactor 最大的特点是使用异步 I/O（Reactor采用的同步IO）。
所有的 I/O *** 作都交由系统提供的异步 I/O 接口去执行。
工作线程仅仅负责业务逻辑。
在 Proactor 中，用户函数启动一个异步的文件 *** 作。
同时将这个 *** 作注册到多路复用器上。
多路复用器并不关心文件是否可读或可写而是关心这个异步读 *** 作是否完成。
异
步 *** 作是 *** 作系统完成，用户程序不需要关心。
多路复用器等待直到有完成通知到来。
当 *** 作系统完成了读文件 *** 作——将读到的数据复制到了用户先前提供的缓冲区之后，通知多路复用器相关 *** 作已完成。
多路复用器再调用相应的处理程序，处理数据。
Proactor 增加了编程的复杂度，但给工作线程带来了更高的效率。
Proactor 可以在系统态将读写优化，利用 I/O 并行能力，提供一个高性能单线程模型。
在 windows 上，由于没有 epoll 这样的机制，因此提供了 IOCP 来支持高并发， 由于 *** 作系统做了较好的优化，windows 较常采用 Proactor 的模型利用完成端口来实现服务器。
在 linux 上，在2.6 内核出现了 aio 接口，但 aio 实际效果并不理想，它的出现，主要是解决 poll 性能不佳的问题，但实际上经过测试，epoll 的性能高于 poll+aio，并且 aio 不能处理 accept，因此 linux 主要还是以 Reactor 模型为主。
本文的代码源码以及使用可在GitHub下载链接: link.
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）