socket server的N种并发模型1
需积分: 0 83 浏览量
2022-08-03
21:47:43
上传
评论
收藏 1.08MB PDF 举报
<编程设计及通论>
第5讲：socket server的N种并发模型
作者:刘冰Aceld
课程标 解socket server的常并发模型及优缺点
前置要求
socket络编程
多IO复机制
多进程、多线程的并发论
模型、单线程Accept（IO复）
模型分析
① 主线程main thread执阻塞Accept，每次客户端Connect链接过来，main thread中accept响应并建连接
② 创建链接成功，得到Connfd1套接字后, 依然在main thread处套接字读写，并处业务。
③ 在②处业务中，如果有新客户端Connect过来，Server响应，直到当前套接字全部业务处完毕。
④ 当前客户端处完后，完毕链接，处下个客户端请求。
优缺点
优点 socket编程流程清晰且简单，适合学习使，解socket基本编程流程。
缺点
该模型并并发模型，是的服务，同时刻，监听并响应最的络请求为1。 即并发为1。
仅适合学习基本socket编程，适合任何服务Server构建。
模型、单线程Accept+多线程读写业务（IO复）
模型分析
① 主线程main thread执阻塞Accept，每次客户端Connect链接过来，main thread中accept响应并建连接
② 创建链接成功，得到Connfd1套接字后，创建个新线程thread1来处客户端的读写业务。main thead依然回到
Accept阻塞等待新客户端。
③ thread1通过套接字Connfd1与客户端进通信读写。
④ server在②处业务中，如果有新客户端Connect过来，main thread中Accept依然响应并建连接，重复②过程。
优缺点
优点
基于模型： 持并发的特性
使笔记灵活，个客户端对应个线程单独处，server处业务的内聚性较，客户端
论如何写、服务端均会有个线程做资源响应。
缺点
随着客户端的数增多，需要开辟的线程的数也增加， 客户端和server线程的数1：1正
关系。因此对于并发场景，线程数受到硬件的瓶颈。线程过多也会增加CPU的切换成
本，降低CPU的率。
对于链接，客户端旦业务读写，只要关闭，server就应该对保持这个链接的状态(
跳检测，健康检查机制)， 占连接资源和线程的开销
仅适合客户端数，并且是可控的场景来使
适合学习基本的socket编程，适合做并发服务
模型三、单线程多IO复
模型分析
① 主线程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复机制阻塞，其他链接过来重复 ②、③流程。
优缺点
优点
单流程体解决可以同时监听多个客户端读写状态的模型，需要1：1客户端的线程数关系
多I/O复，阻塞，忙轮询状态，浪费CPU资源，对CPU率较
缺点
虽然可以监听多个客户端读写状态，但是同时间内，只能够处个客户端的读写操作，实际上读写业务并发为1
当多个客户端访问server， 业务是执，请求的会有排队延迟的现象。如Client3占据main thread流程时，
client1和client2流程会卡在IO复等待下次监听触发事件。
模型四、单线程多IO复+多线程读写业务(业务作池)
模型分析
① 主线程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写给对。
优缺点
优点
对于模型三，将业务的处部分，通过作池分离出来。能够减少客户端访问Server导致业务执
会有请求拍短的延迟时间。
实际上读写的业务并发为1，但是业务流程的并发为worker pool线程数，加快业务处的并效率。
缺点
读写依然是main thread单独处，最的读写并通道依然为1
虽然多个worker线程处业务，但是最后返回给客户端依旧也需要排队。因为出还是main
thraed的read+write 1 个通道
模型五、单线程IO复+多线程IO复(链接线程池)
模型分析
① 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有读写事
件，对应的线程处该套接字的读写及业务。
优缺点
优点
将之前main thread单流程的读写(模型三)，分散到多线程类完成，这样就增加同时刻读写的并通道，并
通道的数N，N就是线程池线程的数
server同时监听的ConnFd套接字的数，乎是成倍增加， 之前的全部的监控数取决于main thread的多IO复
机制的最限制(select 1024, epoll默认与内存有关，约3~6W等)，所以论单点Server最响应并发数
N*(3~6W)（N是线程池的线程数，建议线程的数与CPU核的数是1:1）
如果良好的线程池数和CPU核数适配，那么可以尝试CPU核与Thread进绑定，从降低CPU的切换频率，提升每
个Thread处合业务的效率，降低CPU的切换成本
缺点
虽然监听的并发数提升，但是最的读写并通道依然为N，并且多个身处于同个Thread的客户端，会出现读写延迟
现象。实际上每个Thread模型特征与模型三：单线程多IO复机制是致的。
模型五(进程版)、单进程多I/O复+多进程多I/O复(进程池)
模型分析
与模型五、单线程IO复+多线程IO复(链接线程池)差异。
同点
进程和线程的内存布局同导致，main process(主进程)再进Accept操作，是将Accept过程
分散到各个进程(process)中.
进程的特性，资源独，所以main process如果Accept成功的fd，其他进程法共享资源，所以需
要各进程Accept创建链接
main process只是监听ListenFd状态，旦触发读事件(有新连接请求). 通过些IPC(进程间通信：如信
号、共享内存、管道)等, 让各进程Process竞争Accept完成链接建，并各监听。
优缺点
与模型五、单线程IO复+多线程IO复(链接线程池)差异。
同点
多进程内存资源空间占稍微些
多进程模型安全稳定型较强，这也是因为各进程互扰的特点导致。
模型六、单线程多I/O复+多线程多I/O复+多线程
模型分析
① 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重新加回线程池的监控线程中，同时
身线程我销毁。
优缺点
优点
在模型五基础上，除能够保证同时响应最的并发数，能够解决读写并通道的局限问题
同时刻的读写并通道，达到最化极限， 个客户端可以对应个单独的执流程处读写业务，读写并通道与客户端的数1：1关系
缺点
该模型过于想化，以为要求CPU核数数够
如果硬件CPU数可数，那么该模型就造成的CPU切换的成本浪费。因为为保证读写并通道和客户
端是1：1的关系，就要保证server开辟的thread的数与客户端致。
评论0