服务器Reactor架构浅析

Reactor模式是一个架构模式，它主要解决的问题是高并发场景下的服务器的性能问题。

原来的服务器与客户端的链接是一对一的，也就是说一个客户端socket接到后，对应一个线程去接收和处理，这种模式的好处，是思路很清晰，一个线程处理一个socket请求，但是这种太消耗线程资源，因为毕竟socket不是实时都有数据接入的，例如网卡，就是属于是典型的慢速设备。
因此，如何能高效的利用一些模式，可以改变这种局面，这个时候Reactor模式就出来了：

上图就是基于socket的reactor模式，socket作为文件fd，被多路事件分离器监听，这个多路事件分离器一般就是指Select/poll这种IO多路复用的机制，select/poll将事件分离出来后，委托给反应器去寻找创建对应的事件处理器，当创建完成后，以后有socket事件进来，直接由select分离出来，交由对应的Handler去处理。

Reactor模式其实最初其实来源于 华盛顿大学 Douglas C.Schmdt的一篇论文，最初用于解决分布式日志系统存在慢速设备的问题。论文中的类图如下：

标准的Reactor模式图一共有5个角色：
1、描述符（handle）：
由操作系统提供，用于识别每一个事件，如Socket描述符、文件描述符fd等。在Linux中，它用一个整数来表示。
事件可以来自外部，如来自客户端的连接请求、数据等。事件也可以来自内部，如定时器事件。

2、同步事件分离器（demultiplexer）：

是一个函数，用来等待一个或多个事件的发生。调用者会被阻塞，直到分离器分离的描述符集上有事件发生。
Linux的select/poll/epoll函数是一个经常被使用的分离器。

3、事件处理器接口（event handler）：

是由一个或多个模板函数组成的接口。这些模板函数描述了和应用程序相关的对某个事件的操作。

4、具体的事件处理器：

是事件处理器接口的实现。它实现了应用程序提供的某个服务。也就是libev中的回调函数callback函数。
每个具体的事件处理器总和一个描述符相关。它使用描述符来识别事件、识别应用程序提供的服务。

5、Reactor 管理器（reactor）：

定义了一些接口，用于应用程序控制事件调度，以及应用程序注册、删除事件处理器和相关的描述符。它是事件处理器的调度核心。（如libev中的loop）
Reactor管理器使用同步事件分离器来等待事件的发生。
一旦事件发生，Reactor管理器先是分离每个事件，然后调度事件处理器，最后调用相关的模 板函数来处理这个事件。

其实对Reactor实现的最好实现在C++的ACE框架上，ACE框架用于替代传统socket这种编程方式的，提供了很多封装的模式的框架，其中有一个模式，就叫Reactor框架。
对应：
Reactor对应的就是ACE的Reactor，负责handler注册，和整个Reactor模式的管控；
具体的事件源，也就是handle，其实也就是对应的fd，和socket的文件描述符等事件产生源；
多路复用事件分离器，其实就是操作系统中的select，poll等机制
Event Handler接口就是对应的事件接口，ACE将这个Reactor的接口标准化了，供应用自己去实现自己的Event Handler；
Application Event Handler是对应的应用的事件Handler，继承自Event Handler接口；
对于ACE Reactor框架，还提供了诸如定时任务队列等的支持，功能可谓非常强大。

在Java中，其实大家都非常比较清楚了，NIO其实也比较类似Reactor模式。

Selector可以理解为操作系统底层映射到java API层级的一个多路复用事件的分离器。
SelectionKey其实就是对应的事件，如socket read，socket listen，accept等等。
当对应的事件触发之后，NIO需要你自己针对于SelectionKey中的事件进行if else的判断，而这部分就没有用到Handler，
当然，如ServerSocketChannel，FileChannel对应的事件就那么几个，完全自己可以封装一个完美的Reactor框架。

在我们的libev事件驱动的网络库来说，上述reactor模型的5个角色也都有很明显的对应，类似c++的ACE框架。

总结一下，Reactor模式产生的年头较早，它最初解决的问题是一客户端连接一线程模型中，针对于慢速客户端如打印机等的线程时间片的浪费问题，
后期逐渐演变为服务器前端架构模式，ACE，libev，JAVA的NIO都是基于Reactor的实现案例。