Linux IO多路复用模型

---

什么是流

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

---

什么是IO操作

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

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

---

阻塞与非阻塞模型

阻塞

• 阻塞场景: 你有一份快递，家里有个座机，快递到了主动给你打电话，期间你可以休息。

• 非阻塞，忙轮询场景: 你性子比较急躁， 每分钟就要打电话询问快递小哥一次， 到底有没有到，快递员接你电话要停止运输，这样很耽误快递小哥的运输速度。

---

● 阻塞等待

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

● 非阻塞，忙轮询

浪费时间，浪费电话费，占用快递员时间（占用CPU，系统资源）。

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

---

解决阻塞死等待的办法

• 阻塞死等待的缺点

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

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

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

---

办法一：非阻塞、忙轮询

while true {
	for i in 流[] {
		if i has 数据 {
			读 或者 其他处理
		}
	}
}
1
2
3
4
5
6
7

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

---

办法二：select

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

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

while true {
	select(流[]); //阻塞

  //有消息抵达
	for i in 流[] {
		if i has 数据 {
			读 或者 其他处理
		}
	}
}
1
2
3
4
5
6
7
8
9
10

---

办法三：epoll

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

while true {
	可处理的流[] = epoll_wait(epoll_fd); //阻塞

  //有消息抵达，全部放在 “可处理的流[]”中
	for i in 可处理的流[] {
		读 或者 其他处理
	}
}
1
2
3
4
5
6
7
8

---

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

/** 
 * @param size 告诉内核监听的数目 
 * 
 * @returns 返回一个epoll句柄（即一个文件描述符） 
 */
int epoll_create(int size);
1
2
3
4
5
6

使用

int epfd = epoll_create(1000);
1

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

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

---

2. 控制EPOLL

/**
* @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;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

使用

struct epoll_event new_event;

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

epoll_ctl(epfd, EPOLL_CTL_ADD, 5, &new_event);
1
2
3
4
5
6

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

---

3. 等待EPOLL

/**
*
* @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);
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

使用

struct epoll_event my_event[1000];

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

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

---

4. 使用epoll编程主流程骨架

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 进行写操作
		}
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

---

epoll的触发模式

水平触发(LT)

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

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

---

边缘触发(ET)

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

---

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

(1) 服务端

#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("EPOLLIN\n");
                client_fd = my_events[i].data.fd;

                // do read

                buffer[0] = '\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]: %s\n", buffer);
                    buffer[n] = '\0';
#if 1
                    str_toupper(buffer);
                    write(client_fd, buffer, strlen(buffer));
                    printf("[write]: %s\n", 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("EPOLLOUT\n");
                /*
                   client_fd = my_events[i].data.fd;
                   str_toupper(buffer);
                   write(client_fd, buffer, strlen(buffer));
                   printf("[write]: %s\n", 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;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143

(2) 客户端

#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 \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 error\n");
        exit(0);
    }

    setnoblocking(sockfd);

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



    // 不断的从标准输入字符串
    while (fgets(input, 100, stdin) != NULL)
    {
        printf("[send] %s\n", 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] = '\0';
                printf("[recv] %s\n", recvline);
                break;
            }
        }
    }

    return 0;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107

---

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

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 {
          ....
     ]
   } 
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

---

模型五、单线程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就是类似模型五进程版的改版)。

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