Linux IO多路复用模型

2022-09-29 13:08:49 浏览数 (1)

Linux IO多路复用模型

  • 什么是流
  • 什么是IO操作
  • 阻塞与非阻塞模型
    • 阻塞
    • 解决阻塞死等待的办法
      • 办法一:非阻塞、忙轮询
      • 办法二:select
      • 办法三:epoll
    • Select和Poll模式
    • Epoll模式
      • epoll的API
        • 1. 创建EPOLL
        • 2. 控制EPOLL
        • 3. 等待EPOLL
        • 4. 使用epoll编程主流程骨架
      • epoll的触发模式
        • 水平触发(LT)
        • 边缘触发(ET)
  • 简单的epoll服务器(C语言)
  • Linux网络Server的N种并发模型
    • 模型一、单线程Accept(无IO复用)
    • 模型二、单线程Accept 多线程读写业务(无IO复用)
    • 模型三、单线程多路IO复用
    • 模型四、单线程多路IO复用 多线程读写业务(业务工作池)
    • 模型五、单线程IO复用 多线程IO复用(链接线程池)
    • 模型五(进程版)、单进程多路I/O复用 多进程多路I/O复用(进程池)
    • 模型六、单线程多路I/O复用 多线程多路I/O复用 多线程
  • 总结

什么是流

流指的是可以进行I/O操作的内核对象,例如: 文件,管道和套接字等,流的入口就是文件描述符fd。


什么是IO操作

所有对流的读写操作,我们都可以称之为IO操作。

当一个流中, 在没有数据read的时候,或者说在流中已经写满了数据,再write,我们的IO操作就会出现一种现象,就是阻塞现象,如下图。


阻塞与非阻塞模型

阻塞

  • 阻塞场景: 你有一份快递,家里有个座机,快递到了主动给你打电话,期间你可以休息。
  • 非阻塞,忙轮询场景: 你性子比较急躁, 每分钟就要打电话询问快递小哥一次, 到底有没有到,快递员接你电话要停止运输,这样很耽误快递小哥的运输速度。

● 阻塞等待

空出大脑可以安心睡觉, 不影响快递员工作(不占用CPU宝贵的时间片)。

● 非阻塞,忙轮询

浪费时间,浪费电话费,占用快递员时间(占用CPU,系统资源)。

很明显,阻塞等待这种方式,对于通信上是有明显优势的, 那么它有哪些弊端呢?


解决阻塞死等待的办法

  • 阻塞死等待的缺点

也就是同一时刻,你只能被动的处理一个快递员的签收业务,其他快递员打电话打不进来,只能干瞪眼等待。那么解决这个问题,家里多买N个座机, 但是依然是你一个人接,也处理不过来,需要用影分身术创建多个自己来接电话(采用多线程或者多进程)来处理。

这种方式就是没有多路IO复用的情况的解决方案, 但是在单线程计算机时代(无法影分身),这简直是灾难。

那么如果我们不借助影分身的方式(多线程/多进程),该如何解决阻塞死等待的方法呢?


办法一:非阻塞、忙轮询

代码语言:javascript复制
while true {
	for i in 流[] {
		if i has 数据 {
			读 或者 其他处理
		}
	}
}

非阻塞忙轮询的方式,可以让用户分别与每个快递员取得联系,宏观上来看,是同时可以与多个快递员沟通(并发效果)、 但是快递员在于用户沟通时耽误前进的速度(浪费CPU)。


办法二:select

我们可以开设一个代收网点,让快递员全部送到代收点。这个网店管理员叫select。这样我们就可以在家休息了,麻烦的事交给select就好了。当有快递的时候,select负责给我们打电话,期间在家休息睡觉就好了。

但select 代收员比较懒,她记不住快递员的单号,还有快递货物的数量。她只会告诉你快递到了,但是是谁到的,你需要挨个快递员问一遍。

代码语言:javascript复制
while true {
	select(流[]); //阻塞

  //有消息抵达
	for i in 流[] {
		if i has 数据 {
			读 或者 其他处理
		}
	}
}

办法三:epoll

epoll的服务态度要比select好很多,在通知我们的时候,不仅告诉我们有几个快递到了,还分别告诉我们是谁谁谁。我们只需要按照epoll给的答复,来询问快递员取快递即可。

代码语言:javascript复制
while true {
	可处理的流[] = epoll_wait(epoll_fd); //阻塞

  //有消息抵达,全部放在 “可处理的流[]”中
	for i in 可处理的流[] {
		读 或者 其他处理
	}
}

Select和Poll模式

Select和Poll模式在reids网络模型篇中已经做出了详细的介绍,这里就不展开讲述了:

Redis原理篇之网络模型


Epoll模式

详细也是参考下面这篇文章,本文再对Epoll做出一些小补充说明:

Redis原理篇之网络模型

● 与select,poll一样,对I/O多路复用的技术

● 只关心“活跃”的链接,无需遍历全部描述符集合

● 能够处理大量的链接请求(系统可以打开的文件数目)

Epoll所支持的文件描述符上限是整个系统最大可以打开的文件数目,例如: 在1GB内存的机器上,这个歌限制大概在10万左右。

每个fd上面有个callback函数,只有活跃的socket才会主动去调用callback函数,其他idle状态的socket则不会。

并且Epoll采用内核和用户态共享内存模式,避免了内存的拷贝。


epoll的API

1. 创建EPOLL
代码语言:javascript复制
/** 
 * @param size 告诉内核监听的数目 
 * 
 * @returns 返回一个epoll句柄(即一个文件描述符) 
 */
int epoll_create(int size);

使用

代码语言:javascript复制
int epfd = epoll_create(1000);

创建一个epoll句柄,实际上是在内核空间,建立一个root根节点,这个根节点的关系与epfd相对应。

注意: 当创建好epoll句柄后,它就会占用一个fd值,在使用完epoll后,必须调用close函数进行关闭,否则可能会导致fd被耗尽。


2. 控制EPOLL
代码语言:javascript复制
/**
* @param epfd 用epoll_create所创建的epoll句柄
* @param op 表示对epoll监控描述符控制的动作
*
* EPOLL_CTL_ADD(注册新的fd到epfd)
* EPOLL_CTL_MOD(修改已经注册的fd的监听事件)
* EPOLL_CTL_DEL(epfd删除一个fd)
*
* @param fd 需要监听的文件描述符
* @param event 告诉内核需要监听的事件
*
* @returns 成功返回0,失败返回-1, errno查看错误信息
*/
int epoll_ctl(int epfd, int op, int fd,
struct epoll_event *event);


struct epoll_event {
	__uint32_t events; /* epoll 事件 */
	epoll_data_t data; /* 用户传递的数据 */
}

/*
 * events : {EPOLLIN, EPOLLOUT, EPOLLPRI,
						 EPOLLHUP, EPOLLET, EPOLLONESHOT}
 */
typedef union epoll_data {
	void *ptr;
	int fd;
	uint32_t u32;
	uint64_t u64;
} epoll_data_t;

使用

代码语言:javascript复制
struct epoll_event new_event;

new_event.events = EPOLLIN | EPOLLOUT;
new_event.data.fd = 5;

epoll_ctl(epfd, EPOLL_CTL_ADD, 5, &new_event);

创建一个用户态的事件,绑定到某个fd上,然后添加到内核中的epoll红黑树中。


3. 等待EPOLL
代码语言:javascript复制
/**
*
* @param epfd 用epoll_create所创建的epoll句柄
* @param event 从内核得到的事件集合
* @param maxevents 告知内核这个events有多大,
* 注意: 值 不能大于创建epoll_create()时的size.
* @param timeout 超时时间
* -1: 永久阻塞
* 0: 立即返回,非阻塞
* >0: 指定微秒
*
* @returns 成功: 有多少文件描述符就绪,时间到时返回0
* 失败: -1, errno 查看错误
*/
int epoll_wait(int epfd, struct epoll_event *event,
							 int maxevents, int timeout);

使用

代码语言:javascript复制
struct epoll_event my_event[1000];

int event_cnt = epoll_wait(epfd, my_event, 1000, -1);

epoll_wait是一个阻塞的状态,如果内核检测到IO的读写响应,会抛给上层的epoll_wait, 返回给用户态一个已经触发的事件队列,同时阻塞返回。开发者可以从队列中取出事件来处理,其中事件里就有绑定的对应fd是哪个(之前添加epoll事件的时候已经绑定)。


4. 使用epoll编程主流程骨架
代码语言:javascript复制
int epfd = epoll_crete(1000);

//将 listen_fd 添加进 epoll 中
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd,&listen_event);

while (1) {
	//阻塞等待 epoll 中 的fd 触发
	int active_cnt = epoll_wait(epfd, events, 1000, -1);

	for (i = 0 ; i < active_cnt; i  ) {
		if (evnets[i].data.fd == listen_fd) {
			//accept. 并且将新accept 的fd 加进epoll中.
		}
		else if (events[i].events & EPOLLIN) {
			//对此fd 进行读操作
		}
		else if (events[i].events & EPOLLOUT) {
			//对此fd 进行写操作
		}
	}
}

epoll的触发模式

水平触发(LT)

水平触发的主要特点是,如果用户在监听epoll事件,当内核有事件的时候,会拷贝给用户态事件,但是如果用户只处理了一次,那么剩下没有处理的会在下一次epoll_wait再次返回该事件。

这样如果用户永远不处理这个事件,就导致每次都会有该事件从内核到用户的拷贝,耗费性能,但是水平触发相对安全,最起码事件不会丢掉,除非用户处理完毕。


边缘触发(ET)

边缘触发,相对跟水平触发相反,当内核有事件到达, 只会通知用户一次,至于用户处理还是不处理,以后将不会再通知。这样减少了拷贝过程,增加了性能,但是相对来说,如果用户马虎忘记处理,将会产生事件丢的情况。


简单的epoll服务器(C语言)

(1) 服务端

代码语言:javascript复制
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>

#include <sys/epoll.h>

#define SERVER_PORT (7778)
#define EPOLL_MAX_NUM (2048)
#define BUFFER_MAX_LEN (4096)

char buffer[BUFFER_MAX_LEN];

void str_toupper(char *str)
{
    int i;
    for (i = 0; i < strlen(str); i   ) {
        str[i] = toupper(str[i]);
    }
}

int main(int argc, char **argv)
{
    int listen_fd = 0;
    int client_fd = 0;
    struct sockaddr_in server_addr;
    struct sockaddr_in client_addr;
    socklen_t client_len;

    int epfd = 0;
    struct epoll_event event, *my_events;

    / socket
        listen_fd = socket(AF_INET, SOCK_STREAM, 0);

    // bind
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    server_addr.sin_port = htons(SERVER_PORT);
    bind(listen_fd, (struct sockaddr*)&server_addr, sizeof(server_addr));

    // listen
    listen(listen_fd, 10);

    // epoll create
    epfd = epoll_create(EPOLL_MAX_NUM);
    if (epfd < 0) {
        perror("epoll create");
        goto END;
    }

    // listen_fd -> epoll
    event.events = EPOLLIN;
    event.data.fd = listen_fd;
    if (epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &event) < 0) {
        perror("epoll ctl add listen_fd ");
        goto END;
    }

    my_events = malloc(sizeof(struct epoll_event) * EPOLL_MAX_NUM);


    while (1) {
        // epoll wait
        int active_fds_cnt = epoll_wait(epfd, my_events, EPOLL_MAX_NUM, -1);
        int i = 0;
        for (i = 0; i < active_fds_cnt; i  ) {
            // if fd == listen_fd
            if (my_events[i].data.fd == listen_fd) {
                //accept
                client_fd = accept(listen_fd, (struct sockaddr*)&client_addr, &client_len);
                if (client_fd < 0) {
                    perror("accept");
                    continue;
                }

                char ip[20];
                printf("new connection[%s:%d]n", inet_ntop(AF_INET, &client_addr.sin_addr, ip, sizeof(ip)), ntohs(client_addr.sin_port));

                event.events = EPOLLIN | EPOLLET;
                event.data.fd = client_fd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &event);
            }
            else if (my_events[i].events & EPOLLIN) {
                printf("EPOLLINn");
                client_fd = my_events[i].data.fd;

                // do read

                buffer[0] = '';
                int n = read(client_fd, buffer, 5);
                if (n < 0) {
                    perror("read");
                    continue;
                }
                else if (n == 0) {
                    epoll_ctl(epfd, EPOLL_CTL_DEL, client_fd, &event);
                    close(client_fd);
                }
                else {
                    printf("[read]: %sn", buffer);
                    buffer[n] = '';
#if 1
                    str_toupper(buffer);
                    write(client_fd, buffer, strlen(buffer));
                    printf("[write]: %sn", buffer);
                    memset(buffer, 0, BUFFER_MAX_LEN);
#endif

                    /*
                       event.events = EPOLLOUT;
                       event.data.fd = client_fd;
                       epoll_ctl(epfd, EPOLL_CTL_MOD, client_fd, &event);
                       */
                }
            }
            else if (my_events[i].events & EPOLLOUT) {
                printf("EPOLLOUTn");
                /*
                   client_fd = my_events[i].data.fd;
                   str_toupper(buffer);
                   write(client_fd, buffer, strlen(buffer));
                   printf("[write]: %sn", buffer);
                   memset(buffer, 0, BUFFER_MAX_LEN);

                   event.events = EPOLLIN;
                   event.data.fd = client_fd;
                   epoll_ctl(epfd, EPOLL_CTL_MOD, client_fd, &event);
                   */
            }
        }
    }

END:
    close(epfd);
    close(listen_fd);
    return 0;
}

(2) 客户端

代码语言:javascript复制
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <strings.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <fcntl.h>

#define MAX_LINE (1024)
#define SERVER_PORT (7778)

void setnoblocking(int fd)
{
    int opts = 0;
    opts = fcntl(fd, F_GETFL);
    opts = opts | O_NONBLOCK;
    fcntl(fd, F_SETFL);
}

int main(int argc, char **argv)
{
    int sockfd;
    char recvline[MAX_LINE   1] = {0};

    struct sockaddr_in server_addr;

    if (argc != 2) {
        fprintf(stderr, "usage ./client <SERVER_IP>n");
        exit(0);
    }


    // 创建socket
    if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
        fprintf(stderr, "socket error");
        exit(0);
    }


    // server addr 赋值
    bzero(&server_addr, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(SERVER_PORT);

    if (inet_pton(AF_INET, argv[1], &server_addr.sin_addr) <= 0) {
        fprintf(stderr, "inet_pton error for %s", argv[1]);
        exit(0);
    }


    // 链接服务端
    if (connect(sockfd, (struct sockaddr*) &server_addr, sizeof(server_addr)) < 0) {
        perror("connect");
        fprintf(stderr, "connect errorn");
        exit(0);
    }

    setnoblocking(sockfd);

    char input[100];
    int n = 0;
    int count = 0;



    // 不断的从标准输入字符串
    while (fgets(input, 100, stdin) != NULL)
    {
        printf("[send] %sn", input);
        n = 0;
        // 把输入的字符串发送 到 服务器中去
        n = send(sockfd, input, strlen(input), 0);
        if (n < 0) {
            perror("send");
        }

        n = 0;
        count = 0;


        // 读取 服务器返回的数据
        while (1)
        {
            n = read(sockfd, recvline   count, MAX_LINE);
            if (n == MAX_LINE)
            {
                count  = n;
                continue;
            }
            else if (n < 0){
                perror("recv");
                break;
            }
            else {
                count  = n;
                recvline[count] = '';
                printf("[recv] %sn", recvline);
                break;
            }
        }
    }

    return 0;
}

Linux网络Server的N种并发模型

模型一、单线程Accept(无IO复用)

(1) 模型结构图

(2) 模型分析

① 主线程main thread执行阻塞Accept,每次客户端Connect链接过来,main thread中accept响应并建立连接

② 创建链接成功,得到Connfd1套接字后, 依然在main thread串行处理套接字读写,并处理业务。

③ 在②处理业务中,如果有新客户端Connect过来,Server无响应,直到当前套接字全部业务处理完毕。

④ 当前客户端处理完后,完毕链接,处理下一个客户端请求。


(3) 优缺点

优点:

● socket编程流程清晰且简单,适合学习使用,了解socket基本编程流程。

缺点:

● 该模型并非并发模型,是串行的服务器,同一时刻,监听并响应最大的网络请求量为1。 即并发量为1。 ● 仅适合学习基本socket编程,不适合任何服务器Server构建。


模型二、单线程Accept 多线程读写业务(无IO复用)

(1) 模型结构图

(2) 模型分析

① 主线程main thread执行阻塞Accept,每次客户端Connect链接过来,main thread中accept响应并建立连接

② 创建链接成功,得到Connfd1套接字后,创建一个新线程thread1用来处理客户端的读写业务。main thead依然回到Accept阻塞等待新客户端。

③ thread1通过套接字Connfd1与客户端进行通信读写。

④ server在②处理业务中,如果有新客户端Connect过来,main thread中Accept依然响应并建立连接,重复②过程。


(3) 优缺点

优点:

● 基于模型一:单线程Accept(无IO复用) 支持了并发的特性。 ● 使用灵活,一个客户端对应一个线程单独处理,server处理业务内聚程度高,客户端无论如何写,服务端均会有一个线程做资源响应。

缺点:

● 随着客户端的数量增多,需要开辟的线程也增加,客户端与server线程数量1:1正比关系,一次对于高并发场景,线程数量收到硬件上限瓶颈。 ● 对于长链接,客户端一旦无业务读写,只要不关闭,server的对应线程依然需要保持连接(心跳、健康监测等机制),占用连接资源和线程开销资源浪费。 ● 仅适合客户端数量不大,并且数量可控的场景使用。

仅适合学习基本socket编程,不适合任何服务器Server构建。


模型三、单线程多路IO复用

(1) 模型结构图

(2) 模型分析

① 主线程main thread创建listenFd之后,采用多路I/O复用机制(如:select、epoll)进行IO状态阻塞监控。有Client1客户端Connect请求,I/O复用机制检测到ListenFd触发读事件,则进行Accept建立连接,并将新生成的connFd1加入到监听I/O集合中。

② Client1再次进行正常读写业务请求,main thread的多路I/O复用机制阻塞返回,会触该套接字的读/写事件等。

③ 对于Client1的读写业务,Server依然在main thread继续执行,此时如果有新的客户端Connect链接请求过来,Server将没有即时响应。

④ 等到Server处理完一个连接的Read Write操作,继续回到多路I/O复用机制阻塞,其他链接过来重复 ②、③流程。


(3) 优缺点

优点:

● 单流程解决了可以同时监听多个客户端读写状态的模型,不需要1:1与客户端的线程数量关系。 ● 多路I/O复用阻塞,非忙询状态,不浪费CPU资源, CPU利用率较高。

缺点:

● 虽然可以监听多个客户端的读写状态,但是同一时间内,只能处理一个客户端的读写操作,实际上读写的业务并发为1。 ● 多客户端访问Server,业务为串行执行,大量请求会有排队延迟现象,如图中⑤所示,当Client3占据main thread流程时,Client1,Client2流程卡在IO复用等待下次监听触发事件。


模型四、单线程多路IO复用 多线程读写业务(业务工作池)

(1) 模型结构图

(2) 模型分析

① 主线程main thread创建listenFd之后,采用多路I/O复用机制(如:select、epoll)进行IO状态阻塞监控。有Client1客户端Connect请求,I/O复用机制检测到ListenFd触发读事件,则进行Accept建立连接,并将新生成的connFd1加入到监听I/O集合中。

② 当connFd1有可读消息,触发读事件,并且进行读写消息

main thread按照固定的协议读取消息,并且交给worker pool工作线程池, 工作线程池在server启动之前就已经开启固定数量的thread,里面的线程只处理消息业务,不进行套接字读写操作

④ 工作池处理完业务,触发connFd1写事件,将回执客户端的消息通过main thead写给对方。

此时依旧是由主线程利用epoll或者select等IO多路复用模型,来监控客户端连接,和客户端socket的读写事件。线程池中的线程只是负责处理主线程读取出来的消息。


(3) 优缺点

优点:

● 对于模型三, 将业务处理部分,通过工作池分离出来,减少多客户端访问Server,业务为串行执行,大量请求会有排队延迟时间。 ● 实际上读写的业务并发为1,但是业务流程并发为worker pool线程数量,加快了业务处理并行效率。

缺点:

● 读写依然为main thread单独处理,最高读写并行通道依然为1. ● 虽然多个worker线程处理业务,但是最后返回给客户端,依旧需要排队,因为出口还是main thread的Read Write

代码语言:javascript复制
while(1){
   //等待感兴趣事件发生
   int num=epoll_wait(....,events,...)
   //处理就绪事件
   for event:events {
      if event==read {
           //主线程从socket读取数据
           msg=readMsgFromEvent(event);
          //将数据交给线程池中某个线程进行处理
          thread=worker_pool.poll() 
          //当前线程内部处理完业务后
          //触发event的写事件,将回执客户端的消息通过main thead写给对方
          thread.handle(msg)
     }else if event==write {
          ....
     ]
   } 
}

模型五、单线程IO复用 多线程IO复用(链接线程池)

(1) 模型结构图


(2) 模型分析

① Server在启动监听之前,开辟固定数量(N)的线程,用Thead Pool线程池管理

② 主线程main thread创建listenFd之后,采用多路I/O复用机制(如:select、epoll)进行IO状态阻塞监控。有Client1客户端Connect请求,I/O复用机制检测到ListenFd触发读事件,则进行Accept建立连接,并将新生成的connFd1分发给Thread Pool中的某个线程进行监听。

③ Thread Pool中的每个thread都启动多路I/O复用机制(select、epoll),用来监听main thread建立成功并且分发下来的socket套接字。

④ 如图, thread监听ConnFd1、ConnFd2, thread2监听ConnFd3,thread3监听ConnFd4. 当对应的ConnFd有读写事件,对应的线程处理该套接字的读写及业务。


(3) 优缺点

优点:

● 将main thread的单流程读写,分散到多线程完成,这样增加了同一时刻的读写并行通道,并行通道数量N, N为线程池Thread数量。

● server同时监听的ConnFd套接字数量几乎成倍增大,之前的全部监控数量取决于main thread的多路I/O复用机制的最大限制(select 默认为1024, epoll默认与内存大小相关,约3~6w不等),所以理论单点Server最高响应并发数量为(3~6W)(N为线程池Thread数量,建议与CPU核心成比例1:1)。

● 如果良好的线程池数量和CPU核心数适配,那么可以尝试CPU核心与Thread进行绑定,从而降低CPU的切换频率,提升每个Thread处理合理业务的效率,降低CPU切换成本开销。

缺点:

● 虽然监听的并发数量提升,但是最高读写并行通道依然为N,而且多个身处同一个Thread的客户端,会出现读写延迟现象,实际上每个Thread的模型特征与模型三:单线程多路IO复用一致。


模型五(进程版)、单进程多路I/O复用 多进程多路I/O复用(进程池)

(1) 模型结构图

(2) 模型分析

与五、单线程IO复用 多线程IO复用(链接线程池)无大差异。

不同处

● 进程和线程的内存布局不同导致,main process(主进程)不再进行Accept操作,而是将Accept过程分散到各个子进程(process)中.

● 进程的特性,资源独立,所以main process如果Accept成功的fd,其他进程无法共享资源,所以需要各子进程自行Accept创建链接

● main process只是监听ListenFd状态,一旦触发读事件(有新连接请求). 通过一些IPC(进程间通信:如信号、共享内存、管道)等, 让各自子进程Process竞争Accept完成链接建立,并各自监听。


(3) 优缺点

与五、单线程IO复用 多线程IO复用(链接线程池)无大差异。

不同处:

多进程内存资源空间占用稍微大一些

多进程模型安全稳定型较强,这也是因为各自进程互不干扰的特点导致。


模型六、单线程多路I/O复用 多线程多路I/O复用 多线程

(1) 模型结构图


(2) 模型分析

① Server在启动监听之前,开辟固定数量(N)的线程,用Thead Pool线程池管理

② 主线程main thread创建listenFd之后,采用多路I/O复用机制(如:select、epoll)进行IO状态阻塞监控。有Client1客户端Connect请求,I/O复用机制检测到ListenFd触发读事件,则进行Accept建立连接,并将新生成的connFd1分发给Thread Pool中的某个线程进行监听。

③ Thread Pool中的每个thread都启动多路I/O复用机制(select、epoll),用来监听main thread建立成功并且分发下来的socket套接字。一旦其中某个被监听的客户端套接字触发I/O读写事件,那么,会立刻开辟一个新线程来处理I/O读写业务。

④ 但某个读写线程完成当前读写业务,如果当前套接字没有被关闭,那么将当前客户端套接字如:ConnFd3重新加回线程池的监控线程中,同时自身线程自我销毁。


(3) 优缺点

优点:

● 在模型五、单线程IO复用 多线程IO复用(链接线程池)基础上,除了能够保证同时响应的最高并发数,又能解决读写并行通道局限的问题。 ● 同一时刻的读写并行通道,达到最大化极限,一个客户端可以对应一个单独执行流程处理读写业务,读写并行通道与客户端数量1:1关系。

缺点:

● 该模型过于理想化,因为要求CPU核心数量足够大。 ● 如果硬件CPU数量可数(目前的硬件情况),那么该模型将造成大量的CPU切换成本浪费。因为为了保证读写并行通道与客户端1:1的关系,那么Server需要开辟的Thread数量就与客户端一致,那么线程池中做多路I/O复用的监听线程池绑定CPU数量将变得毫无意义。 ● 如果每个临时的读写Thread都能够绑定一个单独的CPU,那么此模型将是最优模型。但是目前CPU的数量无法与客户端的数量达到一个量级,目前甚至差的不是几个量级的事。


总结

综上,我们整理了7中Server的服务器处理结构模型,每个模型都有各自的特点和优势,那么对于多少应付高并发和高CPU利用率的模型,目前多数采用的是模型五(或模型五进程版,如Nginx就是类似模型五进程版的改版)。

至于并发模型并非设计的约复杂越好,也不是线程开辟的越多越好,我们要考虑硬件的利用与和切换成本的开销。模型六设计就极为复杂,线程较多,但以当今的硬件能力无法支撑,反倒导致该模型性能极差。所以对于不同的业务场景也要选择适合的模型构建,并不是一定固定就要使用某个来应用。

0 人点赞