Proactor#xff0c;同步

事件、信号及定时事件。

有两种高效的事件处理模式Reactor和

Proactor同步

Proactor都是一种基于「事件分发」的网络编程模式区别在于

Reactor

Reactor可以理解为来了事件是由操作系统通知应用程序让应用程序来处理。

又因为【内核中的数据准备阶段和数据就绪并由内核态切换到用户态】这两个过程对应用层来说是需要主动调用read来等待的所以Reactor一般都是用同步IO实现。

Proactor可以理解为来了事件是由操作系统处理好了之后再通知应用程序。

又因为【内核中会由异步线程把数据准备好并且处理好了之后直接通过信号中断告诉应用层】对于应用程序来说得到的是已经完成读写的事件这个过程不需要等待。

因此Proactor一般都是用异步IO实现的。

Linux基本上逐步实现了POSIX兼容但并没有参加正式的POSIX认证。

由于Linux下的异步IO不完善aio_read,aio_write系列函数是由POSIX定义的异步操作接口不是真正操作系统级别支持的而是在用户空间模拟出来的异步并且仅支持本地文件的aio异步操作网络编程中的socket是不支持的。

所以本文没有讲述异步IO实现Proactor模式取而代之的是同步IO模拟实现Proactor模式。

①同步IO实现reactor模式主线程只负责监听lfdaccept成功之后把新创建的cfd交给子线程。

子线程再通过IO多路复用去监听cfd的读写数据并且处理客户端业务。

主线程把已被触发但是还未完成的事件分发给子线程

·································································································

②同步IO模拟proactor模式是主线程accpet监听lfd并且lfd读事件触发时建立连接并创建cfd并且通过epoll_ctl把cfd注册到内核的监听树中等到该socket的读事件就绪时主线程进行读操作把读到的内容交给子线程去进行业务处理然后子线程处理完业务之后把该socketfd又注册为写时间就绪并且把数据交回给主线程由主线程写回给客户端。

主线程模拟真实Proactor模式中的异步线程把已完成的事件分发给子线程

2️⃣模型五线程池版本

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

理论上

只要是做服务器开发那么常见的模型是通用的C/C/go等等都是通用的因为这是一种设计思想。

其中模型四和模型五是实际开发中主流的而模型六过于理想化目前的硬件无法实现。

模型一单线程accept无IO复用

①主线程执行阻塞accept每次客户端connect请求连接过来主线程中的accept响应并建立连接

②创建连接成功之后得到新的套接字文件描述符cfd用于与客户端通信然后在主线程串行处理套接字读写并处理业务。

③在②的处理业务时如果有新的客户端发送请求连接会被阻塞服务器无响应直到当前的cfd全部业务处理完毕重新回到accept阻塞监听状态时才会从请求队列中选取第一个lfd进行连接。

优缺点

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

该模型并非并发模型是串行的服务器同一时刻监听并响应最大的网络请求量为1。

仅适合学习基本socket编程不适合任何服务器Server构建。

相关视频推荐

6种epoll的设计方法单线程epoll、多线程epoll、多进程epoll及每种epoll的应用场景

免费学习地址c/c

Linux服务器架构师学习资料加qun812855908获取资料包括C/CLinuxgolang技术NginxZeroMQMySQLRedisfastdfsMongoDBZK流媒体CDNP2PK8SDockerTCP/IP协程DPDKffmpeg等免费分享

模型二单线程accept

①主线程执行accept阻塞监听每当有客户端connect连接请求过来主线程中的accept响应并且与客户端建立连接

②创建连接成功后得到新的cfd然后再thread_create一个新的线程用来处理客户端的读写业务并且主线程马上回到accept阻塞监听继续等待新客户端的连接请求

④服务器在②处理业务中如果有新客户端发送申请连接过来主线程accept依然会响应并且简历连接重复②过程。

优缺点

使用灵活一个client对应一个thread单独处理server处理业务的内聚程度高一个好的内聚模块应当恰好做一件事。

客户端无论如何写服务端都会有一个线程做资源响应。

随着客户端的数量增多需要开辟的线程也增加客户端与服务端线程数量是11正比关系。

因此对于高并发场景线程数量收到硬件的瓶颈制约。

线程过多也会增加CPU的切换成本降低CPU的利用率。

对于长连接客户端一旦没有业务读写操作只要客户端不关闭服务端的对应线程就必须要保持连接心跳包、健康监测等机制占用连接资源和线程的开销

模型三单线程多路IO复用

lfd之后采用多路IO复用机制如select和epoll进行IO状态阻塞监听。

有client1客户端

connect

IO复用机制检测到lfd触发事件读写则进行accept建立连接并将新生成的cfd1加入到监听IO集合中。

②client1

再次进行正常读写业务请求主线程的多路IO复用机制阻塞返回主线程与client1进行读写通信业务。

等到读写业务结束后会再次返回多路IO复用的地方进行阻塞监听。

③如果client1正在进行读写业务时server依然在主线程执行流程中继续执行此时如果有新的客户端申请连接请求server将没有办法及时响应因为是单线程server正在读写将会把这些还没来得及响应的请求加入阻塞队列中。

④等到server处理完一个客户端连接的读写操作时继续回到多路IO复用机制处阻塞其他的连接如果再发送连接请求过来的话会继续重复②③流程。

优缺点

单线程/单进程解决了可以同时监听多个客户端读写状态的模型不需要11与客户端的线程数量关系。

而是1n

多路IO复用阻塞不需要一直轮询所以不会浪费CPU资源CPU利用效率较高。

因为是单线程/单线程虽然可以监听多个客户端的读写状态但是在同一时间内只能处理一个客户端的读写操作实际上读写的业务并发为1

多客户端访问服务器但是业务为串行执行大量请求会有排队延迟现象。

如图中⑤所示当client3占据主线程流程时

client1和client2流程会卡在IO复用等待下次监听触发事件。

可以该模型编写代码较简单虽然有延迟现象但是毕竟多路IO复用机制阻塞不会占用CPU资源如果并发请求量比较小客户端数量可数允许信息有一点点延迟可以使用该模型。

比如Redis就是采用该模型设计的因为Redis业务处理主要是在内存中完成的操作速度很快性能瓶颈不在CPU上。

模型四单线程多路IO复用

lfd之后采用多路IO复用机制如select和epoll进行IO状态阻塞监听。

有client1客户端

connect

IO复用机制检测到lfd触发事件读写则进行accept建立连接并将新生成的cfd1加入到监听IO集合中。

pool工作线程池工作线程池在server启动之前就已经开启固定数量的线程里面的线程只处理消息业务不进行套接字读写操作。

④工作池处理完业务触发cfd1写事件将要回发客户端的数据消息通过主线程写回给客户端

优缺点

pool业务线程池将业务处理部分从主线程抽离出来为主线程分担了业务处理的工作减少了因为单线程的串行执行业务机制多客户端对server的大量请求造成排队延迟的时间。

就是说主线程读完数据之后马上就丢给了线程池去处理然后马上回到多路IO复用的阻塞监听状态。

缩短了其他客户端的等待连接时间。

由于是单线程实际上读写的业务并发还是为1但是业务流程的并发数为worker

读写依然是主线程单独处理最高的读写并行通道依然是1导致当前服务器的并发性能依然没有提升只是响应任务的速度快了。

每个客户端的排队时间短了但因为还是只有一个通道进行读写操作因此总体的完成度跟模型3是差不多的。

虽然多个worker线程池处理业务但是最后返回给客户端依旧也需要排队。

因为出口还是只有readwrite

模型三是客户端向server发起请求时需要排队模型四是业务处理完之后回写客户端需要排队。

模型三跟模型四的总体并发效率差不多因为还是一个线程进行读写。

但是对于客户端的体验来说会觉得响应速度变快减少了在服务器的排队时间。

如果客户端数量不多并且各个客户端的逻辑业务有并行需求的话适合用该模型。

模型五单线程多路IO复用

①server在启动监听之前需要创建固定数量N的线程作为thread

②主线程创建lfd之后采用多路IO复用机制如select、epoll进行IO状态阻塞监听。

有client1客户端

connect请求IO复用机制检测到lfd触发读事件则进行accept建立连接并且将新创建的cfd1分发给thread

③thread

pool中的每个thread都启动多路IO复用机制用来监听主线程建立成功并且分发下来的socket套接字cfd。

④如图thread1监听cfd1、cfd2thread2监听cfd3thread3监听cfd4。

线程池里的每一个线程相当于它们所监听的客户端所对应的服务端。

当对应的cfd有读写事件时对应的线程池里的thread会处理相应的读写业务。

优缺点

将主线程的单流程读写分散到线程池完成这样增加了同一时刻的读写并行通道并行通道数量等于线程池的thread数量N

server同时监听cfd套接字数量几乎成倍增大之前的全部监控数量取决于主线程的多路IO复用机制的最大限制select默认1024epoll默认与内存有关约3~6w不等。

所以该模型的理论单点server最高的响应并发数量为N*3

如果良好的线程池数量和CPU核心数适配那么可以尝试CPU核心与thread绑定从而降低cpu的切换频率提高了每个thread处理业务的效率。

虽然监听的并发数量提升但是最高读写并行通道依然为N而且多个身处被同一个thread所监听的客户端也会出现延迟读写现象。

实际上线程池里每个thread对应客户端的部分相当于模型三。

Memcache

与线程池版没有太大的差异。

需要在服务器启动之前先创建一些守护进程在后台运行。

①进程间资源不共享而线程是共享资源的。

进程和线程的内存布局不同导致主进程不再进行accept操作而是将accept过程分散到每一个子进程中

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

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

自己创建的cfd由自己监听cfd的读写事件

优缺点

由于进程间的资源独立尽管是父子进程也是读时共享写时复制。

因此多进程模型安全稳定性较强各自进程互不干扰。

Nginx就是使用进程池的框架实现的。

不过方案与标准的多

Reactor

①server在启动监听之前开辟固定数量N个线程创建thread

②主线程创建lfd之后采用多路IO复用机制进行IO状态的阻塞监听。

当有client1客户端connect请求多路IO复用机制检测到lfd触发读事件则会进行accept建立连接并把accept后新创建的cfd1分发给thread

③线程池中的每个thread都启动多路IO复用机制用来监听主线程分发下来的socket套接字cfd。

一旦某个被监听的cfd被触发了读写事件该线程池里的thread会立即开辟他的一个子线程与cfd进行读写业务操作。

④当某个读写线程完成当前读写业务时如果当前套接字没有被关闭那么该线程会将当前的cfd套接字重新加回线程池的监听线程中同时自身销毁。

优缺点

在模型五的基础上除了能够保证同时响应的最高并发数又能解决了读写并行通道被局限的问题。

同一时刻的读写并行通道达到最大极限一个客户端可以对应一个单独线程处理读写业务。

读写并行通道与客户端的数量是1

如果硬件cpu数量可数目前的硬件情况就是cpu可数那么该模型将造成大量的cpu切换成本。

为了保证读写并行通道与客户端可以一对一服务那么server需要开辟的线程数量就要与客户端一致那么线程池中多路IO复用的监听线程池绑定CPU数量将会变得毫无意义。

因为使用多路IO复用机制就是为了达到1个线程可以监听多个client。

如果现在的线程数量已经跟客户端数量一致了那多路IO复用就没意义了

如果每个临时的读写线程都能够绑定一个单独的CPU那么此模型将会是最优模型。

但是目前的CPU数量无法与客户端的数量达到一个量级还差得远。

、总结

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

并发模型并且设计得越复杂越好也不是线程开辟越多越好。

真实设计开发中需要考虑硬件的利用和CPU切换成本的开销。

模型六的设计极为复杂线程较多但以当今的硬件能力无法实现反倒导致该模型性能级差。

所以对于不同的业务场景要选择适合的模型构建并不是说固定要使用哪一个要根据实际灵活变动。