只要是做服务器开发，那么常见的模型是通用的，C/C++/go等等都是通用的，因为这是一种设计思想。
其中模型五是实际开发中主流的，而模型六过于理想化目前的硬件无法实现。

模型一：单线程accept（无IO复用）

模型分析：

• ①主线程执行阻塞accept，每次客户端connect请求连接过来，主线程中的accept响应并建立连接
• ②创建连接成功之后，得到新的套接字文件描述符cfd（用于与客户端通信），然后在主线程串行处理套接字读写，并处理业务。
• ③在②的处理业务时，如果有新的客户端发送请求连接，会被阻塞，服务器无响应，直到当前的cfd全部业务处理完毕，重新回到accept阻塞监听状态时，才会从请求队列中选取第一个lfd进行连接。

优缺点：

优点：

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

缺点：

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

模型二：单线程accept + 多线程读写业务（无IO复用）

模型分析：

• ①主线程执行accept阻塞监听，每当有客户端connect连接请求过来，主线程中的accept响应并且与客户端建立连接
• ②创建连接成功后得到新的cfd，然后再thread_create一个新的线程用来处理客户端的读写业务，并且主线程马上回到accept阻塞监听继续等待新客户端的连接请求
• ③这个新的线程通过套接字cfd与客户端进行通信读写
• ④服务器在②处理业务中，如果有新客户端发送申请连接过来，主线程accept依然会响应并且简历连接，重复②过程。

优缺点：

优点：

• 基于模型一作了改进，支持了并发
• 使用灵活，一个client对应一个thread单独处理，server处理业务的内聚程度高（一个好的内聚模块应当恰好做一件事）。客户端无论如何写，服务端都会有一个线程做资源响应。

缺点：

• 随着客户端的数量增多，需要开辟的线程也增加，客户端与服务端线程数量是1：1正比关系。因此对于高并发场景，线程数量收到硬件的瓶颈制约。线程过多也会增加CPU的切换成本，降低CPU的利用率。
• 对于长连接，客户端一旦没有业务读写操作，只要客户端不关闭，服务端的对应线程就必须要保持连接（心跳包、健康监测等机制），占用连接资源和线程的开销
• 仅适合客户端数量不大，并且是可控的场景来使用
• 仅适合学习基本的socket编程，不适合做并发服务器

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

模型分析：

• ①主线程main thread 创建 lfd之后，采用多路IO复用机制（如select和epoll）进行IO状态阻塞监听。有client1客户端 connect 请求， IO复用机制检测到lfd触发事件读写，则进行accept建立连接，并将新生成的cfd1加入到监听IO集合中。
• ②client1 再次进行正常读写业务请求，主线程的多路IO复用机制阻塞返回，主线程与client1进行读写通信业务。等到读写业务结束后，会再次返回多路IO复用的地方进行阻塞监听。
• ③如果client1正在进行读写业务时，server依然在主线程执行流程中继续执行，此时如果有新的客户端申请连接请求，server将没有办法及时响应（因为是单线程，server正在读写），将会把这些还没来得及响应的请求加入阻塞队列中。
• ④等到server处理完一个客户端连接的读写操作时，继续回到多路IO复用机制处阻塞，其他的连接如果再发送连接请求过来的话，会继续重复②③流程。

优缺点：

优点：

• 单线程/单进程解决了可以同时监听多个客户端读写状态的模型，不需要1：1与客户端的线程数量关系。而是1：n；
• 多路IO复用阻塞，不需要一直轮询，所以不会浪费CPU资源，CPU利用效率较高。

缺点：

• 因为是单线程/单线程，虽然可以监听多个客户端的读写状态，但是在同一时间内，只能处理一个客户端的读写操作，实际上读写的业务并发为1；
• 多客户端访问服务器，但是业务为串行执行，大量请求会有排队延迟现象。如图中⑤所示，当client3占据主线程流程时， client1和client2流程会卡在IO复用，等待下次监听触发事件。

是否满足实际开发？
可以！该模型编写代码较简单，虽然有延迟现象，同一时刻只吃处理一个单流程体，但是毕竟多路IO复用机制阻塞，不会占用CPU资源，如果并发请求量比较小，客户端数量可数，允许信息有一点点延迟，可以使用该模型。

·

·

模型四：单线程多路IO复用 + 多线程业务工作池

模型分析：

前两步跟模型三一致

• ①主线程main thread 创建 lfd之后，采用多路IO复用机制（如select和epoll）进行IO状态阻塞监听。有client1客户端 connect 请求， IO复用机制检测到lfd触发事件读写，则进行accept建立连接，并将新生成的cfd1加入到监听IO集合中。
• ②当cfd1有可读消息，触发读事件，并且进行读写消息。
• ③主线程按照固定的协议读取消息，并且交给worker pool工作线程池，工作线程池在server启动之前就已经开启固定数量的线程，里面的线程只处理消息业务，不进行套接字读写操作。
• ④工作池处理完业务，触发cfd1写事件，将要回发客户端的数据消息通过主线程写回给客户端

优缺点：

优点：

• 相比于模型三而言，设计了一个worker pool业务线程池，将业务处理部分从主线程抽离出来，为主线程分担了业务处理的工作，减少了因为单线程的串行执行业务机制，多客户端对server的大量请求造成排队延迟的时间。就是说主线程读完数据之后马上就丢给了线程池去处理，然后马上回到多路IO复用的阻塞监听状态。缩短了其他客户端的等待连接时间。
• 由于是单线程，实际上读写的业务并发还是为1，但是业务流程的并发数为worker pool线程池里的线程数量，加快了业务处理并行效率。

缺点：

• 读写依然是主线程单独处理，最高的读写并行通道依然是1，导致当前服务器的并发性能依然没有提升，只是响应任务的速度快了。每个客户端的排队时间短了，但因为还是只有一个通道进行读写操作，因此总体的完成度跟模型3是差不多的。
• 虽然多个worker线程池处理业务，但是最后返回给客户端依旧也需要排队。因为出口还是只有read+write 这1个通道。因此业务是可以并行了，但是总体的效率是不变的。
• 模型三是客户端向server发起请求时需要排队，模型四是业务处理完之后回写客户端需要排队。

是否满足实际开发？
可以！ 模型三跟模型四的总体并发效率差不多，因为还是一个线程进行读写。读写的总速度大概一致，如果希望任务并行数量比较多的话可以用这种模型。

·

·

·

模型五：单线程多路IO复用 + 多线程多路IO复用（线程池）实际中最常用

模型分析：

• ①server在启动监听之前，需要创建固定数量N的线程，作为thread pool线程池。
• ②主线程创建lfd之后，采用多路IO复用机制（如select、epoll）进行IO状态阻塞监听。有client1客户端 connect请求，IO复用机制检测到lfd触发读事件，则进行accept建立连接，并且将新创建的cfd1分发给thread pool线程池中的某个线程监听。
• ③thread pool中的每个thread都启动多路IO复用机制，用来监听主线程建立成功并且分发下来的socket套接字（cfd）。
• ④如图，thread1监听cfd1、cfd2，thread2监听cfd3，thread3监听cfd4。线程池里的每一个线程相当于它们所监听的客户端所对应的服务端。当对应的cfd有读写时间时，对应的线程池里的thread会处理相应的读写业务。

优缺点：

优点：

• 将主线程的单流程读写，分散到线程池完成，这样增加了同一时刻的读写并行通道，并行通道数量等于线程池的thread数量N；
• server同时监听cfd套接字数量几乎成倍增大，之前的全部监控数量取决于主线程的多路IO复用机制的最大限制（select默认1024，epoll默认与内存有关，约3~6w不等）。所以该模型的理论单点server最高的响应并发数量为N*（3 ~ 6w）。（N为线程池thread的数量，建议与cpu核心数一致）
• 如果良好的线程池数量和CPU核心数适配，那么可以尝试CPU核心与thread绑定，从而降低cpu的切换频率，提高了每个thread处理业务的效率。

缺点：

• 虽然监听的并发数量提升，但是最高读写并行通道依然为N，而且多个身处被同一个thread所监听的客户端也会出现延迟读写现象。实际上线程池里每个thread对应客户端的部分，相当于模型三。

是否满足实际开发？
可以！ 当前主流的线程池框架就是模型五。

`

`

模型五：（多进程版）单线程多路IO复用 + 多进程多路IO复用（进程池）

模型分析：

与线程池版没有太大的差异。需要在服务器启动之前先创建一些守护进程在后台运行。
存在的不同之处：

• ①进程间资源不共享，而线程是共享资源的。进程和线程的内存布局不同导致主进程不再进行accept操作，而是将accept过程分散到每一个子进程中
• ②进程的资源独立，所以主进程如果accept成功cfd，其他的进程是没有办法共享资源的，因此需要各子进程自行accpet创建连接
• ③主进程只是监听listenFd状态，一旦触发读事件或者有新连接请求，通过IPC进程间通信（signal、mmap、fifo等方式）让所有的子进程们进行竞争，抢到lfd读事件资源的子进程会进行accpet操作，监听他们自己所创建出来的套接字cfd。（自己创建的cfd，由自己监听cfd的读写事件）

优缺点：

与线程池版本没有太大差异
优点：

• 由于进程间的资源独立，尽管是父子进程，也是读时共享，写时复制。因此多进程模型安全稳定性较强，各自进程互不干扰。Nginx就是使用进程池的框架实现的。

缺点：

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

·

·

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

模型分析：

• ①server在启动监听之前，开辟固定数量N个线程，创建thread pool线程池。
• ②主线程创建lfd之后，采用多路IO复用机制进行IO状态的阻塞监听。当有client1客户端connect请求，多路IO复用机制检测到lfd触发读事件，则会进行accept建立连接，并把accept后新创建的cfd1分发给thread pool中的某个线程进行监听。
• ③线程池中的每个thread都启动多路IO复用机制，用来监听主线程分发下来的socket套接字cfd。一旦某个被监听的cfd被触发了读写事件，该线程池里的thread会立即开辟他的一个子线程与cfd进行读写业务操作。
• ④当某个读写线程完成当前读写业务时，如果当前套接字没有被关闭，那么该线程会将当前的cfd套接字重新加回线程池的监听线程中，同时自身销毁。

优缺点：

优点：

• 在模型五的基础上，除了能够保证同时响应的最高并发数，又能解决了读写并行通道被局限的问题。
• 同一时刻的读写并行通道达到最大极限，一个客户端可以对应一个单独线程进行处理读写业务。读写并行通道与客户端的数量是1 ：1关系。

缺点：

• 该模型过于理想化，因为要求cpu的核心数足够大
• 如果硬件cpu数量可数（目前的硬件情况就是cpu可数），那么该模型将造成大量的cpu切换成本。为了保证读写并行通道与客户端可以一对一服务，那么server需要开辟的线程数量就要与客户端一致，那么线程池中多路IO复用的监听线程池绑定CPU数量将会变得毫无意义。
• 如果每个临时的读写线程都能够绑定一个单独的CPU，那么此模型将会是最优模型。但是目前的CPU数量无法与客户端的数量达到一个量级，还差得远。

七 、总结

• 上面整理了7种server的服务器处理结构模型，对于应付高并发和高CPU利用率的模型，目前采用最多的是模型五，其中Nginx就是类似模型五进程版的改版。
• 并发模型并且设计得越复杂越好，也不是线程开辟越多越好。真实设计开发中需要考虑硬件的利用和CPU切换成本的开销。模型六的设计极为复杂，线程较多，但以当今的硬件能力无法实现，反倒导致该模型性能级差。所以对于不同的业务场景要选择适合的模型构建，并不是说固定要使用哪一个，要根据实际灵活变动。