理解Reactor模式与Proactor模式

 我在之前的文章中有写过对堵塞非堵塞，同步异步的一些理解，由于最近在看一些netty的资料，并且netty是Reactor模式的一种优秀实现，所以想借此机会简单介绍下我对于常见的两种Io模式的理解，在目前的各种应用中最为常见的要数Reactor模式，因为Proactor模式需要操作系统的支持，所以世面上有很少的关于Proactor模式的实现，Proactor模式是将来的一种趋势，因为硬件和操作系统都在不断的更新，所以今天主要介绍下两者。
 两者的共同点就是两者都是两种I/O多路复用机制 ，都需要使用事件分发器，Reactor翻译为反应器，而Proactor人们更多的翻译为主动器，两者的主要区别就在于，Reactor主要是一种同步的操作，而Proactor是一种与异步的IO相关的模式，一个在乎过程一个在乎结果。
 Reactor模式是基于同步I/O的，而Proactor模式是和异步I/O相关的。在Reactor模式中，事件分发器等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是socket可读写），事件分发器就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。
 在Proactor模式中，事件处理者（或者代由事件分发器发起）直接发起一个异步读写操作（相当于请求），而实际的工作是由操作系统来完成的。发起时，需要提供的参数包括用于存放读到数据的缓存区、读的数据大小或用于存放外发数据的缓存区，以及这个请求完后的回调函数等信息。事件分发器得知了这个请求，它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调。举例来说，在Windows上事件处理者投递了一个异步IO操作（称为overlapped技术），事件分发器等IO Complete事件完成。这种异步模式的典型实现是基于操作系统底层异步API的，所以我们可称之为“系统级别”的或者“真正意义上”的异步，因为具体的读写是由操作系统代劳的。
在Reactor中实现读：
注册读就绪事件和相应的事件处理器。
事件分发器等待事件。
事件到来，激活分发器，分发器调用事件对应的处理器。
事件处理器完成实际的读操作，处理读到的数据，注册新的事件，然后返还控制权。
在Proactor中实现读：
处理器发起异步读操作（注意：操作系统必须支持异步IO）。在这种情况下，处理器无视IO就绪事件，它关注的是完成事件。
事件分发器等待操作完成事件。
在分发器等待过程中，操作系统利用并行的内核线程执行实际的读操作，并将结果数据存入用户自定义缓冲区，最后通知事件分发器读操作完成。
事件分发器呼唤处理器。
事件处理器处理用户自定义缓冲区中的数据，然后启动一个新的异步操作，并将控制权返回事件分发器。
 虽然Proactor模式需要依赖操作系统对异步的IO的支持，并且操作系统的异步IO总存在问题，但是并不代表Proactor没有任何的用武之地，我们可以通过Reactor模式对Proactor进行模拟，在改进方案中，我们将Reactor原来位于事件处理器内的Read/Write操作移至分发器（不妨将这个思路称为“模拟异步”），以此寻求将Reactor多路同步I/O转化为模拟异步I/O。
以读操作为例子，改进过程如下：
注册读就绪事件和相应的事件处理器。并为分发器提供数据缓冲区地址，需要读取数据量等信息。
分发器等待事件（如在select()上等待）。
事件到来，激活分发器。分发器执行一个非阻塞读操作（它有完成这个操作所需的全部信息），最后调用对应处理器。
事件处理器处理用户自定义缓冲区的数据，注册新的事件（当然同样要给出数据缓冲区地址，需要读取的数据量等信息），最后将控制权返还分发器。
如我们所见，通过对多路I/O模式功能结构的改造，可将Reactor转化为Proactor模式。改造前后，模型实际完成的工作量没有增加，只不过参与者间对工作职责稍加调换。
 java中的AIO其实并未实现Linux中的AIO模型，而是采用了这种模拟的IO异步实现了数据的独写操作。以此来获得更高的性能。

另外附一个美团官方的技术博客希望可以帮助大家理解：
https://zhuanlan.zhihu.com/p/23488863