Reactor模式--VS--Proactor模式

一、 Reactor and Proactor

1 概述

IO读写时，多路复用机制都会依赖对一个事件多路分离器，负责把源事件的IO 事件分离出来，分别到相应的read/write事件分离器。涉及到事件分离器的两种模式分别就是 Reactor和Proactor，Reactor是基于同步IO的，Proactor是基于异步IO的。

在Reactor模式中，事件分离者等待某个事件或者可应用或个操作的状态发生(比如文件描述符可读写，或者是socket可读写),事件分离者就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。Reactor模式主要是提高系统的吞吐量，理解反应器模式的例子：Reactor模式，或者叫反应器模式

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

举个例子，将有助于理解Reactor与Proactor二者的差异，以读操作为例(类操作类似)。

在Reactor中实现读：

- 注册读就绪事件和相应的事件处理器

- 事件分离器等待事件

- 事件到来，激活分离器，分离器调用事件对应的处理器。

- 事件处理器完成实际的读操作，处理读到的数据，注册新的事件，然后返还控制权。

与如下Proactor(真异步)中的读过程比较：

- 处理器发起异步读操作(注意：操作系统必须支持异步IO)。在这种情况下，处理器无视IO就绪事件，它关注的是完成事件。

- 事件分离器等待操作完成事件

- 在分离器等待过程中，操作系统利用并行的内核线程执行实际的读操作，并将结果数据存入用户自定义缓冲区，最后通知事件分离器读操作完成。

- 事件分离器呼唤处理器。

- 事件处理器处理用户自定义缓冲区中的数据，然后启动一个新的异步操作，并将控制权返回事件分离器。

可以看出，两个模式的相同点，都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。在结构上，两者也有相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler;

不同点在于，异步情况下(Proactor)，当回调handler时，表示IO操作已经完成;同步情况下(Reactor)，回调handler时，表示IO设备可以进行某个操作(can read or can write)，handler这个时候开始提交操作。

2、Reactor模式

Reactor释义“反应堆”，是一种事件驱动机制。和普通函数调用的不同之处在于：应用程序不是主动的调用某个API完成处理，而是恰恰相反，Reactor逆置了事件处理流程，应用程序需要提供相应的接口并注册到Reactor上，如果相应的时间发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”。使用Libevent也是想Libevent框架注册相应的事件和回调函数；当这些时间发声时，Libevent会调用这些回调函数处理相应的事件（I/O读写、定时和信号）。
用“好莱坞原则”来形容Reactor再合适不过了：不要打电话给我们，我们会打电话通知你。

3、两个模式简单对比

两个模式的相同点：(1)都是对某个IO事件的事件通知(即告诉某个模块，这个IO操作可以进行或已经完成)。(2)在结构上的相同点：demultiplexor负责提交IO操作(异步)、查询设备是否可操作(同步)，然后当条件满足时，就回调handler。

不同点在于：异步情况下(Proactor)，当回调handler时，表示IO操作已经完成；同步情况下(Reactor)，回调handler时，表示IO设备可以进行某个操作(can read or can write)，handler这个时候开始提交操作。

我的理解：两者的根本区别就在于《Unix网络编程第一卷：套接口API》第6章讲解的五种I/O模型，Proactor是基于异步I/O，Reactor是同步I/O（一般是I/O复用）。但是现在的操作系统并不是都能很好的真正支持异步I/O，比如Windows里有真正的异步I/O——IOCP，而Unix、Linux并没有真正实现异步I/O。所以考虑程序移植性以及现在很多服务器基于Unix，Linux；Proactor封装了这种差异，在内部异步事件分离器实现时根据系统的不同调用相应的I/O模式。

二、BIO、NIO、AIO

NIO通常采用Reactor模式，AIO通常采用Proactor模式。AIO简化了程序的编写，stream的读取和写入都有OS来完成，不需要像NIO那样子遍历Selector。Windows基于IOCP实现AIO，Linux只有eppoll模拟实现了AIO。

Java7之前的JDK只支持NIO和BIO，从7开始支持AIO。

4种通信方式：TCP/IP+BIO,TCP/IP+NIO,UDP/IP+BIO,UDP/IP+NIO。

TCP/IP+BIO、

Socket和ServerSocket实现，ServerSocket实现Server端端口监听，Socket用于建立网络IO连接。

不适用于处理多个请求 1.生成Socket会消耗过多的本地资源。2. Socket连接的建立一般比较慢。

BIO情况下，能支持的连接数有限，一般都采取accept获取Socket以后采用一个thread来处理，one connection one thread。无论连接是否有真正数据请求，都需要独占一个thread。

可以通过设立Socket池来一定程度上解决问题，但是使用池需要注意的问题是：1. 竞争等待比较多。 2. 需要控制好超时时间。

TCP/IP+NIO

使用Channel(SocketChannel和ServerSocketChannel)和Selector。

Server端通常由一个thread来监听connect事件，另外多个thread来监听读写事件。这样做的好处是这些连接只有在真是请求的时候才会创建thread来处理，one request one thread。这种方式在server端需要支持大量连接但这些连接同时发送请求的峰值不会很多的时候十分有效。

UDP/IP+BIO

DatagramSocket和DatagramPacket。DatagramSocket负责监听端口以及读写数据，DatagramPacket作为数据流对象进行传输。

UDP/IP是无连接的，无法进行双向通信，除非双方都成为UDP Server。

UDP/IP+NIO

通过DatagramChannel和ByteBuffer实现。DatagramChannel负责端口监听及读写。ByteBuffer负责数据流传输。

如果要将消息发送到多台机器，如果为每个目标机器都建立一个连接的话，会有很大的网络流量压力。这时候可以使用基于UDP/IP的Multicast协议传输，Java中可以通过MulticastSocket和DatagramPacket来实现。

Multicast一般多用于多台机器的状态同步，比如JGroups。SRM,URGCP都是Multicast的实现方式。eBay就采用SRM来实现将数据从主数据库同步到各个搜索节点机器。

参考：http://simpleframework.net/blog/v/20096.html

http://blog.csdn.net/success041000/article/details/6725110