两种IO多路复用方式对比Reactor and Proactor

两种IO多路复用方案:Reactor and Proactor

概述

一般情况下，I/O 复用机制需要事件分享器(event dispatch)。事件分享器的作用，即将那些读写事件源分发给各读写事件的处理者，就像送快递的在楼下喊: 谁的什么东西送了， 快来拿吧。开发人员在开始的时候需要在分享器那里注册感兴趣的事件，并提供相应的处理者(event handlers)，或者是回调函数; 事件分享器在适当的时候会将请求的事件分发给这些handler或者回调函数。

涉及到事件分享器的两种模式称为：Reactor and Proactor。

Reactor模式是基于同步I/O的，而Proactor模式是和异步I/O相关的。 在Reactor模式中，事件分离者等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是socket可读写），事件分离者就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。

而在Proactor模式中，事件处理者(或者代由事件分离者发起)直接发起一个异步读写操作(相当于请求)，而实际的工作是由操作系统来完成的。发起时，需要提供的参数包括用于存放读到数据的缓存区，读的数据大小，或者用于存放外发数据的缓存区，以及这个请求完后的回调函数等信息。事件分离者得知了这个请求，它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调。举例来说，在Windows上事件处理者投递了一个异步IO操作(称有overlapped的技术)，事件分离者等IOCompletion事件完成。 这种异步模式的典型实现是基于操作系统底层异步API的，所以我们可称之为“系统级别”的或者“真正意义上”的异步，因为具体的读写是由操作系统代劳的。

例子

举个例子来更好地理解Reactor与Proactor两种模式的区别。这里我们只关注read操作，因为write操作也是差不多的。下面是Reactor的做法：

• 某个事件处理者宣称它对某个socket上的读事件很感兴趣;
• 事件分离者等着这个事件的发生;
• 当事件发生了，事件分离器被唤醒，这负责通知先前那个事件处理者;
• 事件处理者收到消息，于是去那个socket上读数据了。 如果需要，它再次宣称对这个socket上的读事件感兴趣，一直重复上面的步骤;

下面再来看看真正意义的异步模式Proactor是如何做的：

• 事件处理者直接投递发一个写操作(当然，操作系统必须支持这个异步操作)。 这个时候，事件处理者根本不关心读事件，它只管发这么个请求，它魂牵梦萦的是这个写操作的完成事件。这个处理者很拽，发个命令就不管具体的事情了，只等着别人（系统）帮他搞定的时候给他回个话。
• 事件分离者等着这个读事件的完成(比较下与Reactor的不同);
• 当事件分离者默默等待完成事情到来的同时，操作系统已经在一边开始干活了，它从目标读取数据，放入用户提供的缓存区中，最后通知事件分离者，这个事情我搞完了;
• 事件分享者通知之前的事件处理者: 你吩咐的事情搞定了;
• 事件处理者这时会发现想要读的数据已经乖乖地放在他提供的缓存区中，想怎么处理都行了。如果有需要，事件处理者还像之前一样发起另外一个写操作，和上面的几个步骤一样。

最大区别在于得到通知时：

• reactor做2件事 取数据 + 拿数据做别的处理
• Proactor做1件事 拿数据做别的处理(数据系统已经帮他取好)

模拟Proactor模式

Reactor稍做调整，模拟成异步的Proactor模型(主要是在事件分离器里完成本该事件处理者做的实际读写工作，我们称这种方法为”模拟异步“)，下面的示例可以看看read操作是如何完成的:

• 事件处理者宣称对读事件感兴趣，并提供了用于存储结果的缓存区、- 读数据长度等参数;
• 调试者等待(比如通过select());
• 当有事件到来(即可读)，调试者被唤醒， 调试者去执行非阻塞的读操作(前面事件处理者已经给了足够的信息了)。读完后，它去通知事件处理者。
• 事件处理者这时被知会读操作已完成，它拥有完整的原先想要获取的数据了。

我们看到，通过为分离者(也就上面的调试者)添加一些功能，可以让Reactor模式转换为Proactor模式。所有这些被执行的操作，其实是和Reactor模型应用时完全一致的。我们只是把工作打散分配给不同的角色去完成而已。这样并不会有额外的开销，也不会有性能上的的损失