概述

对于网络服务器后端开发，为满足不同并发场景的需要，一般来说，不外乎几种常见的并发模型，除了一些教学场景常用的单线程、多进程（线程）的服务器实现外，生产用的服务器，一般都会考虑使用IO多路复用模型。

而常见的IO多路复用场景，可以设计得很简单，也可以设计得比较复杂，一般根据业务需要而定。本文总结了一些比较常见的服务器并发模型，基本涵盖了大部分业务场景。在实际业务开发的技术选型时，可根据场景，选取一款稳定、可靠的网络模型，还是十分关键的。

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

在这里插入图片描述

模型分析

主线程main thread执行阻塞accept，每次客户端connect连接过来，main thread中accept响应并建立连接
创建连接成功，得到connect fd套接字后，依然在main thread串行处理套接字读写，并处理业务
在处理业务时，如果有新客户端connect过来，server无响应，直到当前socket全部业务处理完毕（结束while循环）
当前客户端处理完毕之后，关闭连接，处理下一个客户端请求

优缺点

优点

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

缺点

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

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

在这里插入图片描述

模型分析

主线程main thread阻塞在accept，每次客户端 connect连接过来，main thread中accept响应并建立连接
创建连接成功，得到connect fd套接字后，创建一个新的线程thread来处理客户端的读写业务，mian thread依然回到accept阻塞等待新客户端
thread通过套接字connect fd与客户端进行读写操作
server在处理业务时，如果有新的客户端连接过来，main thread中accept依然可以响应并建立连接，重复上述过程

优缺点

优点

基于模型1的优化，支持了并发的特性
使用比较灵活，一个客户端对应一个线程单独处理，server处理业务的内聚性比较高，客户端无论如何读写，服务端均会有一个线程做资源响应

缺点

随着客户端梳理增多，需要开辟的线程数量也增加了，和server线程的数量是1：1的关系，因此对于高并发场景，线程数量受到硬件的瓶颈，线程过多也会增加CPU的切换成本，降低CPU利用率
对于长连接，客户端一旦无业务读写，只要不关闭，server就应该对保持这个连接的状态（心跳检查，健康检查机制），占用连接资源和线程的开销
仅适合客户端数量不大的场景，且可控的场景来使用
该模型仅适合学习基本的socket编程，不适合做并发服务器

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

在这里插入图片描述

模型分析

主线程main thread创建listen fd之后，采用多路IO复用机制（如select、epoll）进行IO状态阻塞监控，有client连接请求，IO 复用机制检测到listen fd触发读事件，则进行accept建立连接，并将新生成的connect fd加入到监听IO集合中
client再次进行正常读写业务请求，main thread的多路IO复用机制阻塞返回，会触发该套接字的读写事件等
对于client的读写业务，server依然在main thread执行流程继续执行，此时如果有新的客户端connect请求过来，server将没有即时响应
等到server处理完一个连接的读写操作，继续回到多路IO复用机制阻塞，其他连接过来才可以正常执行

优缺点

优点

单流程体解决了可以同时监听多个客户端读写状态模型，不需要1：1客户端的线程数量关系
多路IO复用机制是阻塞的，非忙轮询的状态，不会浪费CPU资源，对CPU的利用率较高
对于连接数较多，但是并发不大的场景，或对实时性没有特别严格的场景，该模型已经足够使用

缺点

虽然可以监听读个客户端的读写状态，但是同一时间内，只能够处理一个客户端的读写操作，实际上读写业务并发为1
当多个客户端访问server，业务是串行执行，大量请求的会有排队延迟现象。

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1jEzEboN-1683502674351)(常见IO多路复用并发模型介绍.assets/image-20230507101910587.png)]

模型分析

主线程main thread 创建listen fd后，采用多路IO复用机制（如select、epoll）进行IO状态阻塞监控，有client客户端connect请求，IO复用机制检测到listenfd触发读事件，则进行accept建立连接，并将新生成的connect fd加入到监听IO集合中
当connect fd有可读消息，触发读时间，并进行读写消息
main thread按照固定协议读取消息，并且交给worker pool工作线程池，工作线程池在server启动之前就已经开启固定数量的thread，里面的线程只处理消息业务，不进行套接字读写操作
工作池处理完业务，触发connect fd写事件，将回执客户端的消息通过main thread写给对方
即：main thread只处理IO阻塞监听以及具体的读写操作，读写到的数据交给具体的线程池处理，让main thread专注于处理IO事件
类似于Redis的处理机制

优缺点

优点

将业务处理的部分，通过工作池分离出来，能够减少客户端访问server导致业务串行执行会有大量请求排队的延迟时间
实际上读写的业务并发为1，但是业务流程的并发为线程池数量，加快了业务处理的并行效率

缺点

读写依然是main thread单独处理，最高的读写并行通道依然是1
虽然多个worker thread处理业务，最后返回给client依旧也需要排队，因为出口还是main thread的一个通道

模型五：单线程IO复用 + 多线程IO复用

在这里插入图片描述

模型分析

server在启动监听前，开辟固定数量（N）的线程，用thread poll线程池管理
主线程main thread创建listen fd之后，采用IO多路复用机制（如select、epoll）进行IO状态阻塞监控，有 client 连接请求，IO复用机制检测到listen fd触发读事件，则进行accept建立连接，并将新生成的connect fd分发给thread pool中的某个线程进行监听
thread pool中的每个thread都启动IO多路复用机制，用来监听main thread建立成功并且分发下来的connect fd的读写事件，处理对应的读写业务，并将处理完的结果通过该thread自己的IO多路复用机制回执给客户端

优缺点

优点

将之前的main thread单流程的读写，分散到多线程来完成，这样就增加了同一时刻读写的并行通道，并行通道的数量N，N 就是线程池的数量
server同时监听connect fd的数量，几乎是成倍增加，之前的全部监控数量取决于main thread的多路IO复用机制的最大限制，所以理论上单点server最高响应并发数量应该是之前的N倍（N是线程池数量，建议线程数量和 CPU核心数1：1）
如果良好的线程池数量可CPU核心数适配，那么可以尝试将CPU 与thread绑定，从而降低CPU的切换频率，提高每个thread处理合理业务的效率，降低CPU的切换成本
memchached的并发模型与该模型比较类似

缺点

虽然监听的并发数量提升，但是最高的读写并行通道依然为N，并且多个身处于同一个thread的客户端，会出现读写排队现象，实际上每个thread模型与单线程IO多路复用机制是一致的

模型六：单进程IO 复用 + 多进程IO复用

在这里插入图片描述

模型分析

与单线程IO复用+ 多线程IO 复用（线程池）无太大差异
不同点
- 进程和线程的内存布局不同，导致main process（主进程）不再进行accept操作，而是将accept过分散到各个子进程中
- 进程的特性，资源独立，所以main process如果accept成功的fd，其他进程无法资源共享，所以需要各个进程自行accept创建连接
- main process 只是监听listen fd的状态，一旦触发读事件（有新连接请求），通过一些IPC （进程间通信，如信号、共享内存、管道等），让各自子进程process竞争accpet完成连接建立，并各自监听

优缺点

与单线程IO复用+ 多线程IO 复用（线程池）无太大差异
不同点：
- 多进程内存资源空间占用稍微大一些
- 多进程模型安全稳定性较强，这也是各自进程互不干扰的特点导致
- 实际上每个子进程process都是一个单线程IO多路复用模型

模型七：单线程IO复用+ 多线程IO复用+ 多线程

在这里插入图片描述

模型分析

server在启动监听之前，开辟固定数量（N）的线程，用thread pool线程池管理
主线程main thread创建listen fd之后，采用IO多路复用机制（如select、epoll）进行IO状态阻塞监控，有 client 连接请求，IO复用机制检测到listen fd触发读事件，则进行accept建立连接，并将新生成的connect fd分发给thread pool中的某个线程进行监听
thread pool中的每个thread都启动IO多路复用机制，用来监听main thread建立成功并且分发下来的connect fd的读写事件，一旦有某个connect fd的读写事件被触发，立即开辟一个新的线程开处理IO读写业务
当某个线程处理完当前的读写业务，如果当前connect fd没有被关闭，那么将当前fd重新加回到thread pool的IO复用集合，并将自身线程销毁