Reactor和Proactor模式

Posted 2023-02-23 xiongping_

首先分享一下，我在网上看到的两篇不错的文章：正是这两篇文章才理解了reactor和proactor模式;

 首先就第一篇《Reactor模式，或者叫反应器模式》做一下笔记：

 

刚开店做生意，老板为了给顾客一个美好的印象，给顾客最好的服务，一对一:

 

随着经营的生意越来越好，顾客多了，不能服务员也多吧，那样得支出的成本也太大了，要是一下子来个1000个顾客，难道老板还得养活1000个服务员，没办法，得改变这种服务模式，但又不能让顾客感到这里的服务下降了，怎么办呢？

 

改革以后，有没有觉得和我们平时去大排档啊，街边小吃店的服务模式很相似是不是，

为什么不说和酒店服务很像，其实还真不像，一般XXX星级的饭店的服务，还真是上一种经营模式，为什么他们要这样呢，

因为，他们是高富帅啊，顾客消费也高，自然老板的收入也高，所以老板也乐子不疲啊。我们是屌丝，请客都只是去个大排档就好了。

 

改革后的模式就是reactor模式，顾客通过呼叫服务员（event事件）通知服务员，菜单写好了，服务员就会把菜单交给厨师（事件处理器），厨师就会去做菜了。

 

 

现在知道reactor模式的由来了吧，知道一个事情的始末会让我们更好的理解它。

下面对第二篇《高性能IO设计的Reactor和Proactor模式》做一下笔记：

这里主要是讲reactor模式和proactor模式的区别：其实就是对数据处理方式变了导致监听事件方式也转变了。

当然，如果还是以第一篇那样以饭店的经营模式来讲解的话，proactor模式应该是这样的：

 

我们知道每一个饭店都有自己的招牌菜去吸引顾客。当然，其实这道菜你也会做，只是别人做的比你更好，更美味。有一天，一群高富帅来了这家大拍档：

 

 

老板就是老板，人面广啊，自家厨师不会做，可以让更专业的人去做，省时省事省心啊！

 

其实这里我们都能看出reactor模式和proactor模式的一点点区别了吧！只是还不了解具体的细节。

第二篇《性能IO设计的Reactor和Proactor模式》就是干这个事的，给我们介绍具体细节和区别，我也是读了好几遍，慢慢画个流程图才理解了啊。

其实说到底就是一句广告语：把事情交给更专业的人，你会更开心。

 

好吧，以下是copy过来，做了少少修改的：转换为自己的理解。

        

 

       在高性能的I/O设计中，有两个比较著名的模式Reactor和Proactor模式，其中Reactor模式用于同步I/O，而Proactor运用于异步I/O操作。


       在比较这两个模式之前，我们首先的搞明白几个概念，什么是阻塞和非阻塞，什么是同步和异步；

 

       同步和异步是针对应用程序和内核的交互而言的；

       同步指的是用户进程触发IO操作并等待或者轮询的去查看IO操作是否就绪，

       异步是指用户进程触发IO操作以后便开始做自己的事情，而当IO操作已经完成的时候会得到IO完成的通知。

 

       阻塞和非阻塞是针对于进程在访问数据的时候，根据IO操作的就绪状态来采取的不同方式，说白了是一种读取或者写入操作函数的实现方式；

       阻塞方式下读取或者写入函数将一直等待，

       非阻塞方式下，读取或者写入函数会立即返回一个状态值。

        一般来说I/O模型可以分为：同步阻塞，同步非阻塞，异步阻塞，异步非阻塞IO


同步阻塞IO：

在此种方式下，用户进程在发起一个IO操作以后，必须等待IO操作的完成，只有当真正完成了IO操作以后，用户进程才能运行。Java传统的IO模型属于此种方式！


同步非阻塞IO:

在此种方式下，用户进程发起一个IO操作以后边可返回做其它事情，但是用户进程需要时不时的询问IO操作是否就绪，这就要求用户进程不停的去询问，从而引入不必要的CPU资源浪费。其中目前JAVA的NIO就属于同步非阻塞IO。



异步阻塞IO：

此种方式下是指应用发起一个IO操作以后，不等待内核IO操作的完成，等内核完成IO操作以后会通知应用程序，这其实就是同步和异步最关键的区别，同步必须等待或者主动的去询问IO是否完成，那么为什么说是阻塞的呢？因为此时是通过select系统调用来完成的，而select函数本身的实现方式是阻塞的，而采用select函数有个好处就是它可以同时监听多个文件句柄，从而提高系统的并发性！



异步非阻塞IO:

在此种模式下，用户进程只需要发起一个IO操作然后立即返回，等IO操作真正的完成以后，应用程序会得到IO操作完成的通知，此时用户进程只需要对数据进行处理就好了，不需要进行实际的IO读写操作，因为真正的IO读取或者写入操作已经由内核完成了。目前Java中还没有支持此种IO模型。

搞清楚了以上概念以后，我们再回过头来看看，Reactor模式和Proactor模式。

首先来看看Reactor模式，Reactor模式应用于同步I/O的场景。我们以读操作为例来看看Reactor中的具体步骤：

读取操作：

1. 应用程序注册读就需事件和相关联的事件处理器

2. 事件分离器等待事件的发生

3. 当发生读就需事件的时候，事件分离器调用第一步注册的事件处理器

4. 事件处理器首先执行实际的读取操作，然后根据读取到的内容进行进一步的处理

 

下面我们来看看Proactor模式中读取操作和写入操作的过程：

读取操作：

1. 应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这是区别于Reactor的关键。

2. 事件分离器等待读取操作完成事件

3. 在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作，并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点，Proactor中，应用程序需要传递缓存区。

4. 事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区读取数据，而不需要进行实际的读取操作。

Proactor中写入操作和读取操作，只不过感兴趣的事件是写入完成事件。

从上面可以看出，Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的IO设备.


综上所述，同步和异步是相对于应用和内核的交互方式而言的，同步 需要主动去询问，而异步的时候内核在IO事件发生的时候通知应用程序，而阻塞和非阻塞仅仅是系统在调用系统调用的时候函数的实现方式而已。

 

最后来两张图做个总结：

 

IO设计模式：Reactor和Proactor对比

平时接触的开源产品如Redis、ACE，事件模型都使用的Reactor模式；而同样做事件处理的Proactor，由于操作系统的原因，相关的开源产品也少；这里学习下其模型结构，重点对比下两者的异同点；

反应器Reactor

Reactor模式结构

Reactor包含如下角色：

• Handle 句柄；用来标识socket连接或是打开文件；
• Synchronous Event Demultiplexer：同步事件多路分解器：由操作系统内核实现的一个函数；用于阻塞等待发生在句柄集合上的一个或多个事件；（如select/epoll；）
• Event Handler：事件处理接口
• Concrete Event HandlerA：实现应用程序所提供的特定事件处理逻辑；
• Reactor：反应器，定义一个接口，实现以下功能： 
  1）供应用程序注册和删除关注的事件句柄； 
  2）运行事件循环； 
  3）有就绪事件到来时，分发事件到之前注册的回调函数上处理；

 

“反应”器名字中”反应“的由来： 
“反应”即“倒置”，“控制逆转”,具体事件处理程序不调用反应器，而是由反应器分配一个具体事件处理程序，具体事件处理程序对某个指定的事件发生做出反应；这种控制逆转又称为“好莱坞法则”（不要调用我，让我来调用你）

业务流程及时序图

1. 应用启动，将关注的事件handle注册到Reactor中；
2. 调用Reactor，进入无限事件循环，等待注册的事件到来；
3. 事件到来，select返回，Reactor将事件分发到之前注册的回调函数中处理；

主动器Proactor

Proactor模式结构

Proactor主动器模式包含如下角色

• Handle 句柄；用来标识socket连接或是打开文件；
• Asynchronous Operation Processor：异步操作处理器；负责执行异步操作，一般由操作系统内核实现；
• Asynchronous Operation：异步操作
• Completion Event Queue：完成事件队列；异步操作完成的结果放到队列中等待后续使用
• Proactor：主动器；为应用程序进程提供事件循环；从完成事件队列中取出异步操作的结果，分发调用相应的后续处理逻辑；
• Completion Handler：完成事件接口；一般是由回调函数组成的接口；
• Concrete Completion Handler：完成事件处理逻辑；实现接口定义特定的应用处理逻辑；

业务流程及时序图

1. 应用程序启动，调用异步操作处理器提供的异步操作接口函数，调用之后应用程序和异步操作处理就独立运行；应用程序可以调用新的异步操作，而其它操作可以并发进行；
2. 应用程序启动Proactor主动器，进行无限的事件循环，等待完成事件到来；
3. 异步操作处理器执行异步操作，完成后将结果放入到完成事件队列；
4. 主动器从完成事件队列中取出结果，分发到相应的完成事件回调函数处理逻辑中；

对比两者的区别

主动和被动

以主动写为例： 
Reactor将handle放到select()，等待可写就绪，然后调用write()写入数据；写完处理后续逻辑； 
Proactor调用aoi_write后立刻返回，由内核负责写操作，写完后调用相应的回调函数处理后续逻辑；

可以看出，Reactor被动的等待指示事件的到来并做出反应；它有一个等待的过程，做什么都要先放入到监听事件集合中等待handler可用时再进行操作； 
Proactor直接调用异步读写操作，调用完后立刻返回；

实现

Reactor实现了一个被动的事件分离和分发模型，服务等待请求事件的到来，再通过不受间断的同步处理事件，从而做出反应；

Proactor实现了一个主动的事件分离和分发模型；这种设计允许多个任务并发的执行，从而提高吞吐量；并可执行耗时长的任务（各个任务间互不影响）

优点

Reactor实现相对简单，对于耗时短的处理场景处理高效； 
操作系统可以在多个事件源上等待，并且避免了多线程编程相关的性能开销和编程复杂性； 
事件的串行化对应用是透明的，可以顺序的同步执行而不需要加锁； 
事务分离：将与应用无关的多路分解和分配机制和与应用相关的回调函数分离开来，

Proactor性能更高，能够处理耗时长的并发场景；

缺点

Reactor处理耗时长的操作会造成事件分发的阻塞，影响到后续事件的处理；

Proactor实现逻辑复杂；依赖操作系统对异步的支持，目前实现了纯异步操作的操作系统少，实现优秀的如windows IOCP，但由于其windows系统用于服务器的局限性，目前应用范围较小；而Unix/Linux系统对纯异步的支持有限，应用事件驱动的主流还是通过select/epoll来实现；

适用场景

Reactor：同时接收多个服务请求，并且依次同步的处理它们的事件驱动程序； 
Proactor：异步接收和同时处理多个服务请求的事件驱动程序；

转载：

http://blog.csdn.net/caiwenfeng_for_23/article/details/8458299

http://www.cnblogs.com/me115/p/4452801.html