网络编程 多路复用IO ：select、poll、epoll、水平触发与边缘触发、惊群问题
文章目录
- 多路复用IO
-
- 多路复用IO的概念
- 多路复用IO与多线程/多进程的并发
-
- 多路复用IO模型进行服务器并发处理
- 多线程/多进程进行服务器并发处理
- select
-
- 工作原理
- 接口
- 优缺点
- select的封装
- select模型实现TCP服务器
- poll
-
- 工作原理
- 接口
- 优缺点
- poll模型实现TCP服务器
- epoll
-
- 工作原理
- 接口
- 优缺点
- epoll的封装
- epoll的工作模式
-
- LT模式（水平触发）
- ET模式（边缘触发）
- LT水平触发与ET边缘触发
- epoll LT模式实现TCP服务器
- epoll ET模式实现TCP服务器
- 惊群问题
-
- 多线程环境下惊群问题的解决方法
- 多进程环境下惊群问题的解决方法
多路复用IO
多路复用IO的概念
多路复用IO用于对大量描述符进行IO就绪事件监控，能够让用户只针对就绪了指定事件的描述符进行操作。
IO的就绪事件分为可读、可写、异常
- 可读事件：一个描述符对应的缓冲区中有数据可读
- 可写事件：一个描述符对应的缓冲区中有剩余空间可以写入数据
- 异常事件：一个描述符发生了特定的异常信息
相比较于其他IO方式，多路复用IO 避免了对没有就绪的描述符进行操作而带来的阻塞，同时只针对已就绪的描述符进行操作，提高了效率
在Linux下，操作系统提供了三种模型：select模型、poll模型、epoll模型。
多路复用IO与多线程/多进程的并发
多路复用IO模型进行服务器并发处理
即在单执行流中进行轮询处理就绪的描述符。如果就绪的描述符较多时，很难做到负载均衡（最后一个描述符要等待很长时间，前边的描述符处理完了才能处理它）。
解决这一问题的方法就是在用户态实现负载均衡，规定每个描述符只能读取指定数量的数据，读取了就进行下一个描述符。
多路复用IO模型适用于有大量描述符需要监控，但是同一时间只有少量活跃的场景
多线程/多进程进行服务器并发处理
即操作系统通过轮询调度执行流实现每个执行流中描述符的处理
由于其在内核态实现了负载均衡，所以不需要用户态做过多操作
多路复用适合于IO密集型服务，多进程或线程适合于CPU密集型服务，它们各有各的优势，并不存在谁取代谁的倾向。基于两者的特点，通常可以将多路复用IO和多线程/多进程搭配一起使用。
使用多路复用IO监控大量的描述符，哪个描述符有事件到来，就创建执行流去处理。这样做的好处是防止直接创建执行流而描述符还未就绪，浪费资源。
select
工作原理
-
定义指定监控事件的描述符集合（即位图），初始化集合后，将需要监控指定事件的描述符添加到指定事件（可读、可写、异常）的描述符集合中
-
将描述符集合拷贝到内核当中，对集合中所有描述符进行轮询判断，当描述符就绪或者等待超时后就调用返回，返回后的集合中只剩下已就绪的描述符（未就绪会在位图中置为0）
-
通过遍历描述符，判断哪些描述符还在集合中，就可以知道哪些描述符已经就绪了，开始处理对应的IO时间。
接口
//清空集合
void FD_ZERO(fd_set *set);
//向集合中添加描述符fd
void FD_SET(int fd, fd_set *set);
//从集合中删除描述符fd
void FD_CLR(int fd, fd_set *set);
//判断描述符是否还在集合中
int FD_ISSET(int fd, fd_set *set);
//发起调用将集合拷贝到内核中并进行监控
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
/*
fd:文件描述符
set:描述符位图
nfds:集合中最大描述符数值+1
readfds:可读事件集合
writefds:可写事件集合
exceptfds:异常事件集合
timeout:超时等待时间
timeval结构体有两个成员
struct timeval {
long tv_sec; 毫秒
long tv_usec; 微秒
};
*/
优缺点
缺点：
- select所能监控的描述符数量有上限，由宏__FD_SETSIZE决定，默认是1024个
- select会将集合拷贝到内核中轮询遍历判断描述符是否就绪，效率会随着描述符的增多而越来越低
- select监控完毕后返回的集合中只有已就绪的描述符，移除了未就绪的描述符，所以每次监控都必须要重新将描述符加入集合中，重新拷贝到内核
- select返回的集合是一个位图而不是真正的描述符数组，所以需要用户遍历判断哪个描述符在集合中才能确认其是否就绪
优点：
- select遵循posix标准，可以跨平台移植
- select的超时等待时间较为精确，可以精细到毫秒
select的封装
为了能让select使用更加便利，对其进行一层封装。
#ifndef __SELECT_H_
#define __SELECT_H_
#includeselect模型实现TCP服务器
#includepoll
工作原理
- 定义pollfd结构体数组，将需要监控的描述符以及监控的事件信息添加进去
- 发起监控调用poll，将数组中的数据拷贝到内核当中进行轮询遍历监控，当有描述符就绪或者等待超时后返回，返回时将已就绪的事件添加进pollfd结构体中的revents中（如果没就绪，则为0）
- 监控调用返回后，遍历pollfd数组中的每一个节点的revents，根据对应的就绪时间进行相应操作
接口
struct pollfd
{
int fd; //需要监控的文件描述符
short events; //需要监控的事件
short revents; //实际就绪的事件
};
/*
操作相对简单，如果某个描述符不需要继续监控时，直接将对应结构体中的fd置为-1即可。
*/
//发起监控
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
/*
fds:pollfd数组
nfds:数组的大小
timeout:超时等待时间，单位为毫秒
*/
优缺点
缺点：
- 在内核中轮询判断描述符是否就绪，效率会随着描述符的增加而下降
- 每次调用返回后需要用户自行判断revents才能知道是哪个描述符就绪了哪个事件
- 无法跨平台移植
- 超时等待时间只精确到毫秒
优点：
- poll通过描述符事件结构体的方式将select的描述符集合的操作流程合并在一起，简化了操作
- poll所监控的描述符数量没有限制，需要多少描述符就给多大的数组
- 不需要每次监控都重新定义事件结构体
poll模型实现TCP服务器
#includeepoll
工作原理
struct eventpoll{
....
/*红黑树的根节点，这颗树中存储着所有添加到epoll中的需要监控的事件*/
struct rb_root rbr;
/*双链表中则存放着将要通过epoll_wait返回给用户的满足条件的事件*/
struct list_head rdlist;
....
};
- 在内核中创建eventpoll结构体，返回一个描述符作为操作句柄
- 对需要监控的描述符组织事件结构体，将描述符和对应事件添加到内核的eventpoll结构体中
- 开始监控，epoll的监控是一个异步阻塞操作，他只需要告诉操作系统哪些描述符需要监控，然后这个监控的过程就由系统来完成。操作系统为每一个描述符所需要的事件设置了一个回调函数，一旦对应事件就绪，就会自动调用回调函数，将描述符所对应的epoll_event事件结构体添加到rdllist双向链表中
- 发起监控后，每隔一段时间就会去查看双向链表rdllist是否为空（阻塞操作，除非链表不为空或者超时才会返回），如果不为空则代表有描述符就绪，将就绪的描述符的结构信息添加到epoll_wait传入的events数组中。只需要对events数组进行遍历，判断就绪的是什么事件然后对描述符进行相应处理即可
接口
//在内核中创建eventpoll结构体，返回操作句柄（size为监控的最大数量，但是在linux2.6.8后忽略上限，只需要给一个大于0的数字即可）
int epoll_create(int size);
//组织描述符事件结构体
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
/*
epfd:eventpoll结构体的操作句柄
op:操作的选项，EPOLL_CTL_ADD/EPOLL_CTL_MOD/EPOLL_CTL_DEL
fd:描述符
event:监控描述符对应的事件信息结构体
struct epoll_event
{
uint32_t events; // 要监控的事件，以及调用返回后实际就绪的事件
epoll_data_t data; // 联合体，用来存放各种类型的描述符
};
typedef union epoll_data {
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
*/
//开始监控，当有描述符就绪或者等待超时后调用返回
int epoll_wait(int epfd, struct epoll_event *events,
int maxevents, int timeout);
/*
maxevents:events数组的结点数量
timeout:超时等待时间
返回值为就绪的描述符个数
*/
优缺点
epoll是Linux下性能最高的多路复用IO模型，几乎具备了一切所需的优点
缺点：
- 无法跨平台移植
- 超时等待时间只精确到毫秒
优点：
- 底层用的是红黑树存储，监控的描述符数量没有上限
- 所有的描述符事件信息只需要向内核中拷贝一次
- 监控采用异步阻塞，性能不会随着描述符增多而下降
- 直接返回就绪描述符事件信息，可以直接对就绪描述符进行操作，不需要像select和poll一样遍历判断。
epoll的封装
#ifndef __EPOLL_H_
#define __EPOLL_H_
#includeepoll的工作模式
epoll有两种工作模式，LT模式（水平触发模式）和ET模式（边缘触发模式）。
LT模式（水平触发）
LT模式也就是水平触发模式，是epoll的默认触发模式（select和poll只有这种模式）
触发条件
可读事件：接受缓冲区中的数据大小高于低水位标记，则会触发事件
可写事件：发送缓冲区中的剩余空间大小大于低水位标记，则会触发事件
低水位标记：一个基准值，默认是1
所以简单点说，水平触发模式就是只要缓冲区中还有数据，就会一直触发事件
- 当epoll检测到socket上事件就绪的时候, 可以不立刻进行处理. 或者只处理一部分.
- 如上面的例子, 由于只读了1K数据, 缓冲区中还剩1K数据, 在第二次调用 epoll_wait 时, epoll_wait 仍然会立刻返回并通知socket读事件就绪.
- 直到缓冲区上所有的数据都被处理完, epoll_wait 才不会立刻返回.
- 支持阻塞读写和非阻塞读写
ET模式（边缘触发）
ET模式也就是边缘触发模式，如果我们在第1步将socket添加到epoll_event描述符的时候使用了EPOLLET标志, epoll就会进入ET工作模式
触发条件
可读事件：(不关心接受缓冲区是否有数据）每当有新数据到来时，才会触发事件。
可写事件：剩余空间从无到有的时候才会触发事件
简单点说，ET模式下只有在新数据到来的情况下才会触发事件。这也就要求我们在新数据到来的时候最好能够一次性将所有数据取出，否则不会触发第二次事件，只有等到下次再有新数据到来才会触发。而我们也不知道具体有多少数据，所以就需要循环处理，直到缓冲区为空，但是recv是一个阻塞读取，如果没有数据时就会阻塞等待，这时候就需要将描述符的属性设置为非阻塞，才能解决这个问题
void SetNoBlock(int fd)
{
int flag = fcntl(fd, F_GETFL);
flag |= O_NONBLOCK;
fcntl(fd, F_SETFL, flag);
}
- 当epoll检测到socket上事件就绪时, 必须立刻处理.
- 如上面的例子, 虽然只读了1K的数据, 缓冲区还剩1K的数据, 在第二次调用 epoll_wait 的时候, epoll_wait 不会再返回了.
- 也就是说, ET模式下, 文件描述符上的事件就绪后, 只有一次处理机会.
- ET的性能比LT性能更高( epoll_wait 返回的次数少了很多). Nginx默认采用ET模式使用epoll.
- 只支持非阻塞的读写
LT水平触发与ET边缘触发
所以简单点说，LT就是只要缓冲区中还有数据，就会一直触发事件，而ET模式下只有在新数据到来的情况下才会触发事件。
LT模式的优点主要在于其简单且稳定，不容易出现问题，传统的select和poll都是使用这个模式。但是他也有缺点，就是因为事件触发过多导致效率降低
ET最大的优点就是减少了epoll的触发次数，但是这也带来了巨大的代价，就是要求必须一次性将所有的数据处理完，虽然效率得到了提高，但是代码的复杂程度大大的增加了。Nginx就是默认采用ET模式
还有一种场景适合ET模式使用，如果我们需要接受一条数据，但是这条数据因为某种问题导致其发送不完整，需要分批发送。所以此时的缓冲区中数据只有部分，如果此时将其取出，则会增加维护数据的开销，正确的做法应该是等待后续数据到达后将其补全，再一次性取出。但是如果此时使用的是LT模式，就会因为缓冲区不为空而一直触发事件，所以这种情况下使用ET会比较好。
epoll LT模式实现TCP服务器
#includeepoll ET模式实现TCP服务器
因为ET模式只支持非阻塞的读写，所以需要新增非阻塞读以及非阻塞写的接口，同时要对加入epoll的套接字加上EPOLLET的选项
//非阻塞发送数据，因为ET模式对于读写的响应只处理一次，所以需要通过轮询的将缓冲区一次性读取完
bool SendNoBlock(const std::string& data)
{
ssize_t pos = 0;
ssize_t left_size = data.size();
while (1)
{
ssize_t ret = send(_socket_fd, data.data() + pos, left_size, 0);
if (ret < 0)
{
//尝试重新写入
if (errno == EAGAIN || errno == EWOULDBLOCK)
{
continue;
}
return false;
}
pos += ret;
left_size -= ret;
//如果数据发送完毕
if (left_size <= 0)
{
break;
}
}
return true;
}
//非阻塞接收数据
bool RecvNoBlock(std::string& data)
{
data.clear();
char buff[4096] = {
0 };
while (1)
{
ssize_t ret = recv(_socket_fd, buff, 4096, 0);
//没有内容
if (ret < 0)
{
//尝试重新写入
if (errno == EAGAIN || errno == EWOULDBLOCK)
{
continue;
}
return false;
}
//对端关闭
else if (ret == 0)
{
return false;
}
buff[ret] = '\0';
data += buff;
//如果当前接受数据小于缓冲区长度，则说明数据全部接收完毕,反之则说明还需要多次轮询接收
if (ret < 4096)
{
break;
}
}
return true;
}
#include惊群问题
在一个执行流中，如果添加了特别多的描述符进行监控，则轮询处理就会比较慢。
因此就会采取多执行流的解决方法，在多个执行流中创建epoll,每个epoll监控一部分描述符，使压力分摊。但是可能因为无法确定哪些描述符即将就绪，所以就会让每个执行流都监控所有描述符，谁先抢到事件则谁去处理。
所以当多个执行流同时在等待就绪事件时，如果某个描述符就绪，他就会唤醒全部执行流中的epoll进行争抢，但是此时就只会有一个执行流抢到并执行，而此时其他的执行流都会因为争抢失败而报错，错误码EAGAIN。这就是惊群问题。
惊群问题带来了什么坏处呢？
- 一个就绪事件唤醒了多个执行流，而多个执行流争抢资源，而最终只有一个能够成功，导致了操作系统进行了大量无意义的调度、上下文切换，导致性能大打折扣
- 为了保证线程安全的问题，需要对资源进行加锁保护，增大了系统的开销
多线程环境下惊群问题的解决方法
这种方法其实也就是本篇博客开头提到的一种做法。只使用一个线程进行事件的监控，每当有就绪事件到来时，就将这些事件转交给其他线程去处理，这样就避免了因为多执行流同时使用epoll监控而带来的惊群问题。
多进程环境下惊群问题的解决方法
这里主要借鉴的是lighttpd和nginx的解决方法。
lighttpd的解决思路很简单粗暴，就是直接无视这个问题，事件到来后依旧能够唤醒多个进程来争抢，并且只有一个能成功，其他进程争抢失败后的报错EAGAIN会被捕获，捕获后不会处理这个错误，而是直接无视，就当做没有发生。
nginx的解决思路是其实就是加锁与负载均衡。使用一个全局的互斥锁，每当有描述符就绪，就会让每个进程都去竞争这把锁（如果某个进程当前连接数达到了最大连接数的7/8，也就是其负载均衡点，此时这个进程就不会再去争抢所资源，而是将负载均衡到其他进程上），如果成功竞争到了锁，则将描述符加入进自己的wait集合中，而对于没有竞争到锁的进程，则将其从自己的wait集合中移除，这样就保证了不会让多个进程同一时间进行监控，而是让每个进程都通过竞争锁的方式轮流进行监控，这样保证了同一时间只会有一个进程进行监控，所以惊群问题也得到了解决。
参考资料
高并发网络编程之epoll详解
epoll详解
Linux惊群效应详解
epoll的惊群效应
Apache与Nginx网络模型
[框架]高并发中的惊群效应
Nginx如何解决“惊群”现象