目录
一、功能
二、应用场景
三、多路转接模型的实现
1.select模型
1.1操作流程
1.2相关接口
1.3示例
1.4常见使用方式
1.5优缺点
2.poll模型
2.1操作流程
2.2相关接口
2.3示例
2.4优缺点
3.epoll模型
3.1操作流程
3.2相关接口
3.3常见使用方式
3.4epoll的事件触发方式
3.5优缺点
一、功能
针对大量描述符进行IO事件监控，让进程可以只针对就绪的描述符进行IO操作，提高IO效率，避免针对未就绪描述符操作而导致的效率低或阻塞。
引入：
问题：
以前的tcp服务器，会为每个客户端创建一个套接字，用于与指定客户端进行通信，但是因为不清楚哪个描述符什么时候会有数据到来，因此流程固定：先获取新建连接，然后收发数据，这样就有可能导致程序阻塞。
解决方法1：
多执行流（多线程or多进程），为每个客户端都创建一个单独的执行流负责通信，这样即使一个执行流阻塞，也不会影响其他客户端通信。
缺陷：
多执行流方式简单粗暴，但是占用资源较多。
解决方法2：使用多路转接模型
针对大量描述符进行IO事件监控，可以让进程知道哪个描述符有数据到来，即哪个就绪，就操作哪个。
二、应用场景
多路转接模型：是监控大量描述符，然后针对就绪描述符逐个进行处理。
（1）有大量描述符需要进行IO就绪事件监控，但是同一时间只有少量活跃的场景。
如果有大量描述符进行监控，并且同一时间活跃数量非常多，会导致排在后面的描述符不能及时得到处理。（可搭配多执行流处理解决）
（2）针对单个描述符有收发数据的超时控制的场景。
三、多路转接模型的实现
1.select模型
1.1操作流程
（1）针对不同的IO事件（可读事件，可写事件，异常事件），定义不同的描述符集合，若需要对哪个描述符监控哪个事件，就把这个描述符添加到对应的集合中。
（2）调用监控接口，将集合拷贝到内核中，进行轮询遍历进行监控；当有描述符就绪，或监控超时都没有就绪，则监控返回。
在内核中，先遍历一遍集合，没有描述符就绪，则将描述符添加到内核的IO事件队列，然后等待，被唤醒后，进程会再次遍历集合，判断哪个描述符是否就绪了指定的事件。
注意：监控调用返回之前，会将集合中所有没有就绪的描述符，从集合内移除（即监控调用返回后，集合中只含有就绪的描述符）。
（3）调用返回后，这时判断哪个描述符还在哪个事件的描述符集合中，就表示哪个描述符就绪了哪个事件，从而进行操作。
1.2相关接口
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
nfds：几种事件的描述符集合中，最大的描述符的值+1；
readfds：可读事件的描述符集合；
writefds：可写事件的描述符集合；
exceptfds：异常事件的描述符集合；
timeout：struct timeval{ uint32_t tv_usec; uint32_t tv_sec}；监控超时等待时间；
返回值：
成功，返回就绪的事件个数；出错，返回-1；没有描述符就绪，返回0。
辅助接口：
（1）从set集合中移除fd描述符
void FD_CLR(int fd, fd_set *set);
（2）判断fd描述符是否在集合set中
int FD_ISSET(int fd, fd_set *set);
返回值：存在，返回true；不存在，返回false。
（3）向set集合中添加fd描述符
void FD_SET(int fd, fd_set *set);
（4）初始化清空set集合
void FD_ZREO(fd_set *set);
1.3示例
对标准输入进行可读事件的监控，在描述符可读时从标准输入读取数据。
#include#include#include#include//#includeint main() { fd_set rfds; //1.初始化集合 FD_ZERO(&rfds); while (1) { struct timeval tv; tv.tv_usec = 0; tv.tv_sec = 3;//设置超时时间为3s //2.将标准输入描述符添加到集合中 FD_SET(0, &rfds);//0是标准输入描述符 int max_fd = 0; //因为select会修改rfds集合（返回前会将未就绪的描述符剔除），所以需要在循环内每次添加 int ret = select(max_fd + 1, &rfds, NULL, NULL, &tv); if (ret < 0) { perror("select error!\n"); usleep(1000); continue; } else if (ret == 0) {//没有描述符就绪 printf("wait timeout!\n"); usleep(1000); continue; } //有描述符就绪 for (int i = 0; i <= max_fd; ++i) { if (FD_ISSET(i, &rfds)) {//若i在集合中，说明描述符i就绪 char buf[1024] = {0}; int res = read(i, buf, 1023); if (res < 0) {//接收数据出错 perror("recv error!\n"); FD_CLR(i, &rfds); return -1; } printf("描述符%d就绪, 读取数据为: %s\n", i, buf); } } } return 0;}实现效果：
1.4常见使用方式
封装一个Select类，实例化的每个Select对象都是一个多路转接对象，能够完成对大量描述符的监控，向外界返回就绪的描述符数组。
class Select{ private: fd_set _rfds;//可读事件的描述符集合的备份，每次监控都是从该集合复制一份出来进行监控 int _max_fd; public: Select(){//针对成员变量进行初始化} bool Add(const TCPsocket& sock);//将sock中的描述符fd，添加到rfds可读事件描述符集合中 bool Del(const TCPsocket& sock);//将sock中的描述符fd，从rfds可读事件描述符集合中移除 bool Wait(std::vector& array);//开始监控，返回就绪的描述符的数组};1.5优缺点
优点：
遵循posix标准，跨平台移植性好（在其他平台下也可以使用select实现多路转接）。
缺点：
（1）所能监控的描述符数量有上限。
select的监控集合是一个数组，当作位图使用，因此能监控多少描述符取决于比特位数，_FD_SETSIZE=1024。
（2）select监控原理，需要进行多次轮询遍历集合，会导致监控的描述符越多，效率就越低。
（3）因为select会修改监控集合，所以每次监控都需要重新添加描述符到集合中。
（4）select返回的是就绪的描述符集合，因此需要用户遍历集合查看哪个描述符还在集合中，操作复杂。
2.poll模型
poll模型：也是针对大量描述符进行监控，但是poll的监控是为每个描述符设置了一个事件结构体。
2.1操作流程
（1）定义要监控的描述事件结构体数组，向数组中添加需要监控的描述符及时间信息。
（2）调用监控接口开始监控，将需要监控的数据拷贝到内核中进行监控（监控原理也是多次轮询遍历）。
注意：监控调用返回前，会将描述符实际就绪事件，填充到结构体的revents成员中，若没有就绪事件则置为0。
（3）监控接口调用完毕后，遍历事件结构体数组，通过每个元素的revents成员确定描述符就绪了什么事件，进行对应操作。
2.2相关接口
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
fds：事件结构体的首地址；
nfds：数组中有效元素的个数；
timeout：监控超时时间，以毫秒为单位；
返回值：
返回实际就绪的事件个数；返回0，表示监控超时；返回值小于零，表示出错。
事件结构体pollfd：
struct pollfd{ int fd;//要监控的事件描述符 short events;//针对这个描述符要监控的事件 //POLLIN-可读、POLLOUT-可写 short revents;//监控调用返回后，这个描述符实际就绪的事件};2.3示例
利用poll模型，监控标准输入的可读事件：
#include#include#include#includeint main() { struct pollfd pfds[10]; int poll_count = 0; pfds[0].fd = 0;//设置要监控的描述符是标准输入 pfds[0].events = POLLIN;//针对标准输入要监控的是可读事件 poll_count++; while (1) { int ret = poll(pfds, 1, 3000); if (ret < 0) { perror("poll error!"); usleep(1000); continue; } else if (ret == 0) { printf("poll timeout!\n"); usleep(1000); continue; } for (int i = 0; i < poll_count; ++i) { if (pfds[i].revents & POLLIN) {//就绪了可读事件 char buf[1024] = {0}; read(pfds[i].fd, buf, 1023); printf("描述符%d就绪，读取数据为：%s\n", pfds[i].fd, buf); } else if (pfds[i].revents & POLLOUT) { //就绪的是可写事件，对应操作 } } } return 0;}实现效果：
2.4优缺点
优点：
（1）相较于select模型操作更加简单。
（2）所能监控的描述符数量没有上限。
缺点：
（1）无法跨平台。
（2）监控原理涉及多次轮询遍历，因此效率也会随着监控的描述符数量增加而降低。
3.epoll模型
epoll模型：针对大量描述符进行事件监控（被认为是Linux2.6以后最好用的多路转接模型）。
3.1操作流程
（1）创建epoll句柄
在内核中会创建struct eventpoll，含有两个重要成员：rbr（红黑树）和rdllist（双向链表）。
（2）向epoll添加监控
组织对应事件结构体，添加到epoll红黑树中。
（3）开始监控
注意：
①epoll的监控默认是一个异步阻塞操作。
②epoll开始监控，实际上是告诉系统可以开始监控了，监控过程由系统完成。
③系统在进行监控的时候为每个描述符都定义了一个回调函数，回调函数的功能是：一旦描述符就绪了指定事件，就把描述符对应的事件结构体信息添加到rdllist双向链表中。
④我们的进程则只需要根据rdllist双向链表是否为空，来判断是否有描述符就绪。
3.2相关接口
（1）创建句柄
int epoll_create(int size);
size：所能监控的最大描述符数量，但是在Linux2.6.8之后被忽略（但是必须大于0）。
返回值：
成功，返回epoll句柄-描述符。
注意：在内核中会创建struct eventpoll结构体
（2）添加监控
int epoll_ct(int epfd, int cmd, int fd, struct epoll_event *ev);
epfd：epoll_create返回的操作句柄；
cmd：要进行的操作：EPOLL_CTL_ADD-添加、EPOLL_CTL_DEL-移除、EPOLL_CTL_MOD；
fd：要操作的描述符；
ev：要操作的描述符所对应的事件结构体；
返回值：
成功，返回0；失败返回-1。
（3）开始监控
int epoll_wait(int epfd, struct epoll_event *evs, int maxevents, int timeout);
epfds：epoll操作句柄；
evs：事件结构体的数组首地址，用于存放就绪的事件信息；
maxevents：数组的空间大小（或者说元素个数），防止就绪事件过多，数组空间不够用，因此做的获取就绪事件个数限制。
timeout：监控的超时时间，一毫秒为单位；
返回值：
成功，返回就绪的事件个数；出错，返回-1；超时，返回0。
注意：在调用返回后，evs数组里保存的都是就绪的描述符对应的事件结构体，返回值就是元素的个数，用户就可以直接针对事件结构体中的evs[i].data.fd进行events事件操作。
事件结构体epoll_event：
struct epoll_event{ uint32_t events;//要监控的事件，以及监控返回后实际就绪的事件 //EPOLLIN-可读、EPOLLOUT-可写 epoll_data_t data;//用户数据变量};typedef union epoll_data{ void *ptr; int fd;}epoll_data_t;3.3常见使用方式
封装Epoll类，实例化的对象可以实现对大量描述符的监控，并返回就绪的描述符。
class Epoll{ private: int _epfd;///epoll操作句柄 public: Epoll(){} bool Add(TCPsocket& sock);//对sock描述符添加epoll监控 bool Del(TCPsocket& sock);//移除对sock描述符的监控 bool Wait(std::vector *array, int timeout = 3000);//开始监控};示例：
#include "socket_tcp.hpp"#include #include #include #define EPOLL_MAX 10class Epoll{ private: int _epfd;///epoll操作句柄 public: Epoll():_epfd(-1) { _epfd = epoll_create(1); if (_epfd < 0) { perror("epoll error!"); exit(0); } } bool Add(TCPsocket& sock) {//对sock描述符添加epoll监控 struct epoll_event ev; ev.events = EPOLLIN;//对可读事件进行监控 ev.data.fd = sock.GetFd(); int ret = epoll_ctl(_epfd, EPOLL_CTL_ADD, sock.GetFd(), &ev); if (ret < 0) { perror("epoll_ctl error!"); return false; } return true; } bool Del(TCPsocket& sock){//移除对sock描述符的监控 int ret = epoll_ctl(_epfd, EPOLL_CTL_DEL, sock.GetFd(), NULL); if (ret < 0) { perror("epoll_ctl error!"); return false; } return true; } bool Wait(std::vector *array, int timeout = 3000){//开始监控 struct epoll_event evs[EPOLL_MAX]; int ret = epoll_wait(_epfd, evs, EPOLL_MAX, timeout); if (ret < 0) { perror("epoll_wait error!"); return false; } else if (ret == 0) { printf("epoll timeout!\n"); return false; } //返回ret个就绪的描述符对应的事件结构体，保存在evs中 for (int i = 0; i push_back(sock); } } return true; }};实现效果：
3.4epoll的事件触发方式
（一）水平触发（默认的触发方式）
触发特性：
可读事件：只要接收缓冲区中有数据，就会触发事件。
可写事件：只要发送缓冲区中有剩余空间，就会触发事件。
（二）边缘触发（EPOLLET）
触发特性：
可读事件：只有新数据到来，才会触发事件，若没有新数据到来，无论缓冲区中有没有数据，都不会二次触发事件。
可写事件：发送缓冲区剩余空间大小从无到有，才会触发事件。
作用：为了让程序员一次性将请求处理完毕，减少处理次数，以此提高效率（但实际上提高并不明显）。
问题：这么才能一次性将数据处理完？
通常都是循环读取数据，直到缓冲区中没有数据为止。
注意：但是如果循环读取，缓冲区中没有数据时，recv就会阻塞导致程序卡死，因此边缘触发方式下，通常需要将描述符设置为非阻塞，让描述符的操作都成为非阻塞操作。这样没有数据时，读取则会报错返回。
属性相关接口：
int fcntl(int fd, int cmd, int arg……);
（1）获取描述符属性
int flag = fcntl(fd, F_GETFL, 9);
（2）新增非阻塞属性
fcntl(fd, F_SETFL, flag | O_NONBLOCK);
注意：设置非阻塞属性，是在原先的基础上新增非阻塞属性。且描述符为非阻塞属性，其相关操作也就都是非阻塞操作。
边缘触发适用场景：
（1）想要尽量一次性处理所有请求，减少事件触发次数提高效率。
（2）避免水平触发模式下，因为半条数据没有进行处理，不断触发事件的情况。即缓冲区中数据不完整，想要等到新数据到来，再去取出完整数据进行处理的场景。
3.5优缺点
缺点：
跨平台移植性差。
优点
（1）所能监控的描述符数量没有上限限制。
（2）监控的原理是异步阻塞，让系统进行监控。系统为事件做了回调函数，将就绪事件添加到就绪链表，进程只需要判断就绪链表是否为空，就可以确定是否有描述符就绪，其中不需要轮询遍历操作，因此性能不会随着描述符增多而下降。
（3）直接返回就绪的事件信息，可以直接对就绪的描述符进行指定事件的操作，不需要遍历判断哪个描述符就绪。
select&poll相较于epoll的优点：
虽然针对大量描述符的监控性能没有epoll高，但是在单个描述符的超时控制上，select和poll操作更加轻便。
注：自了解epoll惊群问题。