高性能网络框架笔记四(IO线程模型)
作者:互联网
上一文介绍中,我们详述了网络数据包的接收和发送过程,并通过介绍5中IO模型了解了内核是如何读取网络数据并通知给用户线程的。
前面的内容都是以内核空间的视角来剖析网络数据的收发模型,本小节我们站在用户空间的视角来看一下如何对网络数据进行收发。
相对内核来讲,用户空间的IO线程模型相对简单一些。这些用户空间的IO线程模型都是在讨论当前多线程一起配合工作时谁负责接收连接,谁负责响应IO读写,谁负责计算,谁负责发送和接收,仅仅是用户IO线程的不同分工模式。
1、Reactor
Reactor是利用NIO对IO线程进行不同的分工:
- 使用前面我提到的IO多路复用模型,比如select、poll、epoll,kqueue进行IO事件的注册和监听。
- 将监听到就绪的IO事件分发dispatch到各个具体的处理Handler中进行相应的IO事件处理。
通过IO多路复用技术就可以不断的监听IO事件,不断的分发dispatch,就像一个反应堆一样,看起来像不断的产生IO事件,因此我们称这种模式为Reactor模式。
Reactor模型分三类:
1.1 单Reactor单线程
Reactor是依赖IO多路复用技术实现监听IO事件,从而源源不断的产生IO就绪事件,在Linux系统下我们使用epoll来进行IO多路复用,我们以Linux系统为例:
- 单Reactor意味着只有一个epoll对象,用来监听所有的事件,比如连接事件,读写事件。
- 单线程意味着只有一个线程来执行epoll_wait获取IO就绪的socket,然后对这些就绪的socket执行读写,以及以后的业务处理也依然是这个线程。
单Reactor单线程模型就好比我们开了个很小的饭馆,作为老板的我们需要一个人看所有的事情,包括:迎接顾客(accept事件),为顾客介绍菜单并等待顾客点菜(IO请求),做菜(业务处理),上菜(IO响应),送客(断开连接)
1.2单Reactor多线程
随着客人的增多(并发请求),显然饭馆只有一个人(单线程)干活肯定忙不过来,这时招聘一些员工(多线程)来帮忙干上述事情。
于是就有了单Reactor多线程模型:
- 这种模式下,也是只有一个epoll对象来监听所有的IO事件,一个线程来调用epoll_wait获取IO就绪的socket。
- 但是当IO就绪事件产生时,这些IO事件对应处理的业务Handler,我们是通过线程池来执行。这样相比单Reactor单线程模型提高了执行效率,充分发挥了多核CPU的优势。
1.3主从Reactor多线程
做任何事情都要区分事件的优先级,我们应该优先高效的去做优先级更高的事情,而不是一股脑儿不分优先级的全部去做。
当我们的小饭馆客人越来越多(并发量越来越大),我们就需要扩大饭店的规模,在这个过程中我们发现,迎接客人是饭店最重要的工作,我们要把客人迎进来,不能让客人一看人多就走掉,只要客人进来了,哪怕菜做的慢一点也没关系。
- 我们由原来单Reactor变为了多Reactor。主Reactor用来优先专门做优先级最高的事情,也就是迎接客人(处理连接事件)。
- 创建好连接,简历对应的socket后,在acceptor中将要监听的read事件注册到从Reactor中,由从Reactor来监听socket上的读写事件。
- 最终将读写的业务逻辑交给线程池处理。
注意:这里想从Reactor注册的只是read事件,并没有注册write事件,因为read事件是有epoll内核触发的,而write事件则是由用户业务线程触发的(什么时候发送数据是由具体业务线程决定的),所以write事件理应由用户业务线程去注册。
用户线程注册write事件的时机是只有当用户发送的数据无法一次性全部写入buffer时,才会去注册write事件,等待buffer重新科协时,继续写入剩下的发送数据,如果用哪个好线程一股脑的将发送数据全部写入buffer,那么也就无需注册write事件到从Reactor中。
主从Reactor多线程模型是目前大部分主流网络框架中采用的一种IO线程模型。Netty就是用的这种模型。
2、Preactor
Proactor是基于AIO对IO线程进行分工的一种模型。前面我们介绍了异步IO模型,它是操作系统内核支持的一种全异步编程模型,在数据准备阶段和数据拷贝阶段全程无阻塞。
Proactor线程模型将IO事件的监听,IO操作的执行,IO结果的dispatch统统交给内核来做。
Proactor模型组件介绍:
- completion handler 为用户程序定义了异步IO操作回调函数,在异步IO操作完成时被内核回调通知IO结果。
- completion Event Queue 异步IO操作完成后,会产生对应的IO完成事件,将IO完成事件放到该队列中。
- Asynchronous Operation Processor负责异步IO的执行。执行完成后产生IO完成事件放入completion Event Queue队列中。
- proactor是一个事件循环派发器,负责从completion Event Queue中获取IO完成事件,并回调与IO完成事件关联的completion handler。
- Initiator初始化异步操作(asynchronous operation)并通过asynchronous Operation Processor将completion handler和proactor注册到内核。
Proactor执行过程:
- 用户线程发起aio_read,并告诉内核用户空间的都读缓存地址,以便内核完成IO操作将结果放入用户空间的读缓冲区,用户线程直接可以读取结果(无任何阻塞)。
- Initiator初始化aio_read异步读取操作(asynchronous operation),并将completion handler注册到内核。
在Proactor中我们关系的IO完成事件:内核已经帮助我们读好数据并放入我们指定的读缓冲区,用户线程可以直接读取。在Reactor中我们中我们关系的是IO就绪事件:数据已经到来,但是需要用户线程自己去内核读取。
- 此时用户线程就可以做其他的事情了,无需等待IO结果。而内核与此同事开始异步执行IO操作。当IO操作完成时会产生一个completion event事件,将这个IO完成事件放入completion event queue中。
- Proactor从completion event queue中取出completion event,并回调与IO完成事件关联的completion handler。
- 在completion handler中完成业务逻辑处理。
3、Reactor与Proactor对比
- Reactor是基于NIO实现的一种IO线性模型,Proactor是基于AIO实现的IO线程模型。
- Reactor关心的是IO就绪事件,Proactor关心的是IO完成事件。
- 在Proactor中,用户程序需要向内核传递用户空间的读缓冲区地址。Reactor则不需要。这也就导致了Proactor中没有并发操作都要求有独立的缓冲区,在内存上有一定的开销。
- Proactor的实现逻辑复杂,编码成本较Reactor要高的多。
- Proactor在处理高耗时IO时的性能要过于Reactor,但对于低耗时IO的执行效率提升并不明显。
4、Netty的IO模型
介绍完网络数据包在内核中的收发过程以及五种IO模型和两种线程模型后,线程我们来看下Netty中的IO模型是什么样的。
在我们介绍Reactor IO线程模型的时候提到有三种Reactor模型:单Reactor单线程,单Reactor多线程,主从Reactor多线程。
这三种Reactor模型在netty中都是支持的,但是我们常用的是主从Reactor多线程模型。
而我们之前介绍的三种Reactor只是一种模型,是一种设计思想。实际上各种网络框架在实现中并不是严格按照模型来实现的,会有一些小的不同,但大体设计思想上是一样的。
下面我们来看下netty中的主从Reactor多线程模型是什么样子:
- Reactor在netty中是以group的形式出现的。netty中将Reactor分为两组,一组是MainReactorGroup也就是我们在编码中常常看到的EventLoopGroup bossGroup,另一组是SubReactorGroup也就是我们在编码中常常看到的EventLoopGroup workerGroup。
- MainReactorGroup通常只有一个Reactor,专门负责做重要的事情,也就是监听连接accept事件。当有连接事件产生时,在对应的处理handler acceptor中创建初始化相应的NioSocketChannel(代表一个Socket连接)。然后以负载均衡的方式在SubReactorGroup中选取一个Reactor,注册上去,监听Read事件。
MainReactorGroup中只有一个Reactor的原因是,通常我们的服务端程序只会绑定监听一个端口,如果绑定监听多个端口,就会配置多个Reactor。
- SubReactorGroup中有多个Reactor,具体Reactor的个数可以由系统参数 -D io.netty.evnetLoopThreads指定。默认的Reactor的个数为CPU核数*2。SubReactorGroup中的Reactor主要负责监听读写事件,每个Reactor负责监听一组socket连接。将全部的连接分摊在多个Reactor中。
- 一个Reactor分配一个IO线程,这个IO线程负责从Reactor中获取IO就绪事件,执行IO调用获取IO数据,执行PipeLine。
socket连接在创建后就被固定的分配给一个Reactor,所以一个socket连接也只会被一个固定的IO线程执行,每个socket连接分配一个独立的PipeLine实例,用来编排这个socket连接上的IO处理逻辑。这种无锁串行化的设计目的是为了防止线程并发执行同一个socket连接上的IO逻辑处理,防止出现线程安全问题。同时使系统吞吐量达到最大化
由于每个Reactor中只有一个IO线程,这个IO线程叫执行IO活跃的socket连接对应的Pipeline中的ChannelHandler,又要从Reactor中获取IO就绪事件,执行IO调用。所以Pipeline中channelhandler中执行的逻辑不能耗时太长,尽量将耗时的业务逻辑处理放入单独的业务线程池中处理,否则会影响其它连接的IO读写,从而近一步影响到整个服务程序的IO吞吐。
当IO请求在业务线程中完成相应的业务逻辑处理后,在业务线程中利用持有的ChannelHandlerContext引用将响应数据在Pipeline中反向传播,最终写回给客户端。
netty支持的三种Reactor模型:
配置单Reactor单线程
EventLoopGroup eventGroup = new NioEventLoopGroup(1); ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(eventGroup);
配置单Reactor多线程
EventLoopGroup eventGroup = new NioEventLoopGroup(); ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(eventGroup);
配置主从Reactor多线程
EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(); ServerBootstrap serverBootstrap = new ServerBootstrap(); serverBootstrap.group(bossGroup, workerGroup);
https://mp.weixin.qq.com/s/Wx8_LeqYPnqSKGQKDhrstg
标签:Reactor,模型,高性能,线程,事件,IO,多线程 来源: https://www.cnblogs.com/zhongqifeng/p/16029629.html