首页 中国创投网 > 要闻 > 正文

socketserver服务器开发常见的并发模型

点击左上方蓝色“一口Linux”,选择“设为星标”

两种高效的事件处理模式

服务器程序通常需要处理三类事件:I/O 事件、信号及定时事件。有两种高效的事件处理模式:Reactor和 Proactor,同步 I/O 模型通常用于实现Reactor 模式,异步 I/O 模型通常用于实现 Proactor 模式。

Linux基本上逐步实现了POSIX兼容,但并没有参加正式的POSIX认证。由于Linux下的异步IO不完善,aio_read,aio_write系列函数是由POSIX定义的异步操作接口,不是真正操作系统级别支持的,而是在用户空间模拟出来的异步,并且仅支持本地文件的aio异步操作,网络编程中的socket是不支持的。所以本文没有讲述异步IO实现Proactor模式,取而代之的是同步IO模拟实现Proactor模式。


【资料图】

下面的并发模型中,常用的是:

1️⃣模型四(同步IO模拟proactor模式)

2️⃣模型五线程池版本 (同步IO实现reactor模式)

在客户端数量非常多的时候适合用模型五,但是在客户端数量不多的时候使用模型四可能会效率更好,因为模型四的线程数量更少,减少CPU切换线程的频率。

服务器开发常见的并发模型

只要是做服务器开发,那么常见的模型是通用的,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资源,如果并发请求量比较小,客户端数量可数,允许信息有一点点延迟,可以使用该模型。

比如Redis就是采用该模型设计的,因为Redis业务处理主要是在内存中完成的,操作速度很快,性能瓶颈不在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对应客户端的部分,相当于模型三。

是否满足实际开发?

可以!当前主流的线程池框架就是模型五,其中有Netty 和 Memcache 。

模型六:(多进程版)单线程多路IO复用 + 多进程多路IO复用(进程池)

模型分析:

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

存在的不同之处:

①进程间资源不共享,而线程是共享资源的。进程和线程的内存布局不同导致主进程不再进行accept操作,而是将accept过程分散到每一个子进程中

②进程的资源独立,所以主进程如果accept成功cfd,其他的进程是没有办法共享资源的,因此需要各子进程自行accpet创建连接

③主进程只是监听listenFd状态,一旦触发读事件或者有新连接请求,通过IPC进程间通信(signal、mmap、fifo等方式)让所有的子进程们进行竞争,抢到lfd读事件资源的子进程会进行accpet操作,监听他们自己所创建出来的套接字cfd。(自己创建的cfd,由自己监听cfd的读写事件)

优缺点:

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

优点:

由于进程间的资源独立,尽管是父子进程,也是读时共享,写时复制。因此多进程模型安全稳定性较强,各自进程互不干扰。Nginx就是使用进程池的框架实现的。不过方案与标准的多 Reactor 多进程有些差异。具体差异表现在主进程中仅仅用来初始化 socket,并没有创建 mainReactor 来 accept 连接,而是由子进程的 Reactor 来 accept 连接,通过锁来控制一次只有一个子进程进行 accept(防止出现惊群现象),子进程 accept 新连接后就放到自己的 Reactor 进行处理,不会再分配给其他子进程。

缺点:

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

模型七:单线程多路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数量将会变得毫无意义。(因为使用多路IO复用机制,就是为了达到1个线程可以监听多个client。如果现在的线程数量已经跟客户端数量一致了,那多路IO复用就没意义了)

如果每个临时的读写线程都能够绑定一个单独的CPU,那么此模型将会是最优模型。但是目前的CPU数量无法与客户端的数量达到一个量级,还差得远。

八 、总结

上面整理了7种server的服务器处理结构模型,对于应付高并发和高CPU利用率的模型,目前采用最多的是模型五,其中Nginx就是类似模型五进程版的改版。

并发模型并且设计得越复杂越好,也不是线程开辟越多越好。真实设计开发中需要考虑硬件的利用和CPU切换成本的开销。模型六的设计极为复杂,线程较多,但以当今的硬件能力无法实现,反倒导致该模型性能级差。所以对于不同的业务场景要选择适合的模型构建,并不是说固定要使用哪一个,要根据实际灵活变动。

一口君的新书,感谢大家支持!

精彩文章合集

文章推荐

关键词:

关于本站 管理团队 版权申明 网站地图 联系合作 招聘信息

Copyright © 2005-2023 中国创投网 - cn.xunjk.com All rights reserved
联系我们:39 60 29 14 2@qq.com
皖ICP备2022009963号-3