IO
- 典型 IO 模型
- 阻塞 IO
- 非阻塞 IO
- 信号驱动 IO
- 异步 IO
- 常见问题
- 多路转接模型
- select 模型
- poll 模型
- epoll 模型
典型 IO 模型
IO 操作指的就是数据的输入输出操作;IO 过程可以分为两个步骤:等待 IO 就绪、数据拷贝
阻塞 IO
发起 IO 操作,若当前不具备 IO 条件,则等待直到条件满足完成 IO 后返回
优点:流程简单
缺点:资源利用率低,效率相对低下
非阻塞 IO
发起 IO 操作,若当前能够 IO ,则执行完 IO 操作后返回;若当前不具备 IO 条件则报错返回
优点:对资源利用率提高了
缺点:程序流程复杂–因为要进行循环操作;不是实时的
信号驱动 IO
定义 IO 信号处理方式,IO 就绪通过信号通知进程,然后发起 IO 调用
优点:对资源利用率更充分;IO 操作更实时
缺点:操作流程更加复杂–添加信号通知部分
异步 IO
发起异步 IO 操作,IO 的等待以及数据的拷贝都由系统完成,完成后通知进程
优点:对资源利用率提升;
确定:程序流程也更复杂了
常见问题
阻塞 vs 非阻塞
阻塞:发起一个操作,若当前操作条件不满足则一直等待
非阻塞:发起一个操作,若当前操作条件不满足则报错返回
阻塞与非阻塞关联:通常都是操作接口特性
阻塞与非阻塞区别:发起一个接口调用后,接口是否会立即返回
同步 vs 异步
同步:功能由进程自身来完成,且通常是串行化的
异步:功能并不由进程自身来完成,而是由系统完成的,完成不一定是串行的
同步与异步关联:通常用于讨论一个任务的完成流程
同步与异步区别:功能是否有当前执行流自身完成
异步阻塞:发起操作后, 功能由系统来完成,进程执行流自身等待系统完成
异步非阻塞:发起操作后,功能由系统来完成,操作会直接返回,并不会等待
多路转接模型
常用于高并发服务器中技术的使用
作用:针对大量描述符进行 IO 就绪事件监控
优点:
1:让进程能够仅针对就绪的描述符进行 IO 操作,提高了任务处理效率
2:避免进程因为未就绪描述符进行操作而导致阻塞
具体技术实现:select、poll、epoll
select 模型
IO 事件:可读事件、可写事件、异常事件
流程思想:
1:定义指定 IO 事件的描述符集合;
2:将需要对指定事件进行监控的描述符添加到指定集合中;
3:将事件的描述符集合拷贝到内核中,进行事件监控:
1)对集合中所有描述符进行遍历,若没有就绪则将描述符挂到内核的 IO 事件队列;
2)若监控过程中,有某个描述符就绪了所要监控的事件,则会唤醒进程的阻塞;
3)唤醒后,select 会再次遍历描述符集合,将集合中没有就绪的描述符移除
4:select 监控返回后,只需要判断哪个描述符还在集合中,哪个描述符就就绪了哪个事件;
5:进程可以根据就绪的不同事件对描述符进行不同的 IO 操作
接口介绍
1、定义集合:
fd_set set;
本质上这个集合是一个比特位图,默认拥有 1024 个比特位,取决于 __FD_SETSIZE;因此,select 对描述符进行 IO 事件监控是有最大描述符限制的
2、先初始化集合,然后将需要监控的描述符添加到集合中
初始化清空集合:
void FD_ZERO(fd_set *set);
将 fd 描述符添加到集合中:
void FD_SET(int fd, fd_set *set);
将 fd 描述符从 set 集合移除:
void FD_CLR(int fd, fd_set *set);
3、开始监控:
nt select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
nfds:将所有需要监控的集合中,最大描述符+1,提高监控遍历效率
readfds:可读事件的描述符集合
writefds:可写事件的描述符集合
exceptfds:异常事件的描述符集合
timeout:设置本次监控的阻塞时长; NULL-一直阻塞,直到描述符就绪或被信号打断; 0-非阻塞
返回值:返回实际就绪的描述符事件个数;出错返回 -1;0-监控超时
select 接口一旦返回,就意味着三个集合中,就只保留了就绪了指定事件的描述符
4、判断哪个描述符还在集合中,哪个描述符就绪了哪个事件
int FD_ISSET(int fd, fd_set *set);
返回值:非0-描述符还在集合中;0-描述符不在集合中
Demo:
1 #include<stdio.h>
2 #include<unistd.h>
3 #include<stdlib.h>
4 #include<time.h>
5 #include<sys/select.h>
6
7 /*对标准输入进行可读事件监控,有数据则读取,没有数据则阻塞*/
8
9 int main()
10 {
11 fd_set rfds; //定义可读事件集合
12 while(1){
13 int maxfd=0; //集合中最大描述符个数 --- 因为只对标准输入进行可读事件监控,因此最大描述符 1 个
14 struct timeval tv; //定义时间结构体
15 tv.tv_sec=3; //阻塞 3s;因为 select每次监控都会重置阻塞时间为0,所有每次循环都需要重新设置
16 tv.tv_usec=0;
17
18 FD_ZERO(&rfds); //初始化集合 因为select每次监控都会重置描述符集合,因此每次循环都需要重新添加描述符到集合中
19 FD_SET(0,&rfds); //将标准输入-0,添加到可读集合
20
21 int nfds=select(maxfd+1,&rfds,NULL,NULL,&tv); //开始监控,只有可读集合 rfds
22 if(nfds<0){ //监控失败
23 perror("select error~!\n");
24 return -1;
25 }else if(nfds==0){ //返回值为0,表示没有描述符存在
26 perror("select timeout!\n"); //等待超时
27 continue;
28 }
29
30 //for 循环遍历集合
31 for(int i=0;i<=maxfd;++i){
32 if(FD_ISSET(i,&rfds)!=0){
33 //判断 i 号描述符在可读集合中,说明就绪了可读事件
34 char buf[1024]={0};
35 read(i,buf,1024); //从 i 号描述符中读取数据放入 buf
36 printf("buf:[%s]\n",buf);
37 }
38 //else if(FD_ISSET(i,&efds)) {
39 //判断 i 号描述符在可写事件中,说明就绪了可写事件
40 //}
41 }
42 }
43 return 0;
44 }
运行结果:
将 select 应用在 TCP 服务器搭建上
搭建一个 TCP 服务器,会涉及到服务器为每一个客户端都建立一个新的套接字进行通信,需要对大量的描述符进行 IO 操作;之前介绍 TCP 服务器时候的解决方案是:使用多执行流来处理 – 为每一个客户端的通讯都创建执行流
这里,我们可以使用 多路转接模型+线程池 进行应用
思想:
封装一个 Select 类,每一个实例化的对象,都是一个能够针对大量描述符进行 IO 事件监控的对象 添加链接描述
封装 TCP:添加链接描述
客户端代码:添加链接描述
服务端代码:添加链接描述
select 总结:
优点:遵循 posix 标准,跨平台移植性好; 监控超时可以细微到微妙
缺点:
1.能够监控的描述符数量是有上线限制的 — 取决于 _FD_SETSIZE,默认1024;
2.监控过程中需要多次遍历描述符集合,因此监控的描述符越多,性能就越低;
3.因为每次监控都会修改描述符集合,因此每次监控都需要重新条件描述符到集合中;
4.监控返回的是就绪的描述符集合(位图),因此监控调用返回后,无法直接针对就绪的描述符进行操作,需要遍历一遍描述符看哪个还在集合中才能确定是否就绪了事件
高并发服务器中,有一种并发模型 :reactor 模型
思想:使用多路转接模型对大量描述符进行事件监控,谁触发了事件就处理谁
分类:
1.单 reactor 单线程 :在一个线程中,进行事件监控以及事件处理;
2.单 reactor 多线程 :在一个线程中进行 reactor 事件监控,触发事件后交给其他线程进行事件处理;
3.多 reactor 多线程 :在一个线程中进行新连接到来事件监控,有事件触发则获取新建连接,将新建连接分发给其他 reactor 线程,其他的 reactor 进行描述符的事件监控以及 IO 操作
poll 模型
操作流程:
1.定义一个事件结构体数组
struct poollfd{
int fd; //要监控的文件描述符
short events; //想要监控的事件,POLLIN-可读,POLLOUT-可写
short revents; //监控返回后,存储实际就绪的事件
}
//定义事件结构体数组
struct pollfd fds[MAX];
2.若哪个描述符需要监控什么事件,就在数组中进行设置
fds[0].fd=0;
fds[0].events=POLLIN; //对标准输入进行可读事件监控
fds[1].fd=1;
fds[1].events=POLLOUT; //对标准输出进行可写时间监控
3.开始监控
原理:将数组中有效数据拷贝到内核中,进行多次轮询遍历
第一次遍历:判断有没有就绪的事件,没有则挂起到监控队列中;
第二次遍历:进程的阻塞被唤醒后进行遍历,对每个元素的 revents 设置实际就绪的事件
int poll(struct pollfd*fds,nfds_t maxevents,int timeout);
fds:定义的时间结构体数组首地址
maxevents:数组中有效元素个数
timeout:监控阻塞的超时时间,以毫秒为单位
返回值:>0 表示实际就绪的事件个数; ==0 表示超时; <0 表示出错了
4.调用返回后,遍历事件结构体数组,根据 revents 成员确定描述符是否就绪了某个事件,进而对描述符进行操作
Demon:
#include<stdio.h>
#include<string.h>
#include<unistd.h>
#include<poll.h>
#define MAX_POLL_SIZE 10
int main()
{
//定义事件结构体数组
struct pollfd fds[MAX_POLL_SIZE];
//添加要监控的描述符事件信息
fds[0].fd=0; //标准输入事件
fds[0].events=POLLIN; //监控可读事件
while(1){
int ret=poll(fds,1,3000); //超时时间为 3000 毫秒 --- 3s
if(ret<0){
perror("poll error!\n");
continue;
}
else if(ret==0){
printf("poll timeout!\n");
continue;
}
int i=0,valid_count=1; //只监控可读事件,因此有效监控个数 valid_count=1
for(i=0;i<valid_count;++i){
if(fds[i].revents & POLLIN){ //就绪可读事件
char buf[1024]={0};
read(fds[i].fd,buf,1023);
printf("buf:[%s]\n",buf);
}else if(fds[i].revents & POLLOUT) {
//就绪可写事件
printf("POLLOUT EVENTS!\n");
}
}
}
return 0;
}
运行结果:
poll 总结:
优点:
1.使用事件结构体替代了事件集合,相较于 select 操作,简便性提高了很多;
2.所能监控的描述符数量不在上限限制;
缺点:
1.每次监控需要将信息拷贝到内核;
2.监控原理涉及到多次对事件数组的遍历,因此性能会随着描述符的增多而下降;
3.每次监控完毕后,依然需要遍历整个事件数组才能确定哪个描述符就绪了哪个事件
events = POLLIN | POLLOUT; 对两个事件同时监控采用 |
epoll 模型
操作流程:
1.在内核中创建 epoll 句柄 eventpoll 结构
int epoll_create(int size);
size: 所能监控的描述符上限 ,在Linux 2.6.8 后被忽略,但必须大于 0
返回值:返回 epoll 描述符;出错返回 -1
struct eventpoll{
...
list_head rdllist; //双向链表
rbtree rbr; //红黑树
...
}
2.向内核的句柄中,添加/移除/修改所要监控的描述符及其对应的事件结构
int epoll_ctl(int epfd,int op,int fd,struct epoll_event* ev);
epfd: epoll_create 返回的 epoll 描述符
op: 对 epoll 要进行的操作:EPOLL_CTL_ADD / EPOLL_CTL_DEL / EPOLL_CTL_MOD
fd:要操作的描述符
struck epoll_event* ev; //对描述符要进行操作的详细信息
struct epoll_event{
uint32_t events; //想要监控的事件以及监控后存放实际就绪的事件
union{ //可以监控的事件 : EPOLLIN-可读,EPOLLOUT-可写
void* ptr;
int fd;
}data; //额外信息
};
3.开始监控
epoll 的监控是一个异步阻塞操作
发起监控调用是为了告诉系统,可以开始监控了,监控由系统完成 (而系统内部为 epoll 的每个描述的就绪事件挂了一个回调函数)
回调函数功能:描述符一旦就绪了指定事件,将事件信息拷贝一份到 rdllist 中,其实 rdllist 双向链表的作用:存放就绪的描述符对应的事件结构
一旦系统监控有描述符就绪了,则唤醒进程的阻塞,进程一旦被唤醒,查看 rellist 双向链表中是否有数据就可以确定是否有描述符就绪
监控调用返回的数据就是一个事件结构体数组 – 就绪的描述符对应的事件
int epoll_wait(int epfd,struct epoll_event* evs,int maxevents,int timeout);
epfd: epoll 描述符
evs: epoll_event 结构体数组的空间首地址,接收就绪事件
maxevents: 数组的最大元素个数,也表示了当前想要获取的最大事件个数
timeout: 要设置的监控超时时间 -- 以毫秒为单位
返回值: >0 实际就绪的事件个数;==0 超时 ; <0 出错了
封装一个 Epoll 类
将封装的 epoll 应用于 TCP 通信的操作与 select 应用相同,感兴趣可以自己琢磨琢磨,这里就不放代码咯~
epoll 事件触发方式
水平触发:select 与 poll 只有水平触发,epoll 默认水平触发
可读:缓冲区中数据大小小于高水平标记 (默认1字节)就会触发可读事件
可写:缓冲区中剩余空间大小小于高水平标记,就会触发可写事件
思想:只要满足触发条件就会触发对应事件
边缘触发:
可读:每当套接字有新数据到来时,则会触发一次事件
可写:缓冲区剩余空间从无到有的时候,才会触发一次事件
思想:尽量让用户在一次事件触发中,将能处理的数据都处理完毕,尽量减少事件触发次数,减少运行态切换次数
因为有新数据到来才触发一次事件,因此若一次事件触发后的处理中没有将所有数据进行处理,则在下一次新数据到来前,这些剩余数据都得不到处理
场景:http请求接收 – 在一次请求的接收处理中,发现缓冲区中数据不足以进行一次处理,取出来则需要额外存储,不取出来则水平触发就会一直触发可读事件,这种情况下希望能够在有新数据到来时再去进行数据处理,则使用边缘触发。
Q:如何将数据在一次处理中全部取出进行处理?
若想要将缓冲区中数据全部取出就只能循环取出
但循环读取数据,在套接字 recv 时候,有可能因为 socket 没有数据而阻塞
解决:将套接字的阻塞属性设置为非阻塞
将属性进行设置之后,则套接字的所有操作将变为非阻塞操作
int fcntl(int fd,int op,int arg);
op:F_GETFL 获取文件访问属性以及状态标志
F_SETFL 设置文件的访问属性或状态标志 -- O_NONBLOCK--非阻塞
int flag=fcntl(fd,F_GETFL,0); //获取文件原有属性--第三个参数被忽略
fcntl(fd,F_SETFL,flag|O_NONBLOCK); //在原有属性基础上添加非阻塞属性
epoll 总结:
优点:
1.所能监控的描述符没有数量上限
2.监控性能并不会随着描述符的增多而下降
3.直接返回就绪描述符对应的事件结构,减少外界空遍历
4.描述符监控的事件信息,只需要向内核中添加一次,不需要每次监控都添加
缺点:
跨平台移植性不好,只能在类unix平台下使用
Q:select 、poll、epoll 哪个好?
不管是哪种模型,多路转接模型针对的都是对大量描述符进行 IO 事件监控,但是同一时间少量活跃的场景
若活跃连接也较多,则一定要搭配多执行流进行处理,充分利用系统资源文章来源:https://uudwc.com/A/xG5Yb
相较之下,select & poll 比较适用于单个描述符的事件监控以及超时管理,而 epoll 适用于大量描述符的事件监控场景。文章来源地址https://uudwc.com/A/xG5Yb