转载地址：http://www.cnblogs.com/MikeZhang/archive/2012/08/16/ReactorPattern20120815.html

Reactor模式是处理并发I/O比较常见的一种模式，用于同步I/O，中心思想是将所有要处理的I/O事件注册到一个中心I/O多路复用器上，同时主线程阻塞在多路复用器上；一旦有I/O事件到来或是准备就绪(区别在于多路复用器是边沿触发还是水平触发)，多路复用器返回并将相应I/O事件分发到对应的处理器中。

　　Reactor是一种事件驱动机制，和普通函数调用的不同之处在于：应用程序不是主动的调用某个API完成处理，而是恰恰相反，Reactor逆置了事件处理流程，应用程序需要提供相应的接口并注册到Reactor上，如果相应的事件发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”。用“好莱坞原则”来形容Reactor再合适不过了：不要打电话给我们，我们会打电话通知你。

　　Reactor模式与Observer模式在某些方面极为相似：当一个主体发生改变时，所有依属体都得到通知。不过，观察者模式与单个事件源关联，而反应器模式则与多个事件源关联。

模式框架

1）　Handle

　　Handle代表操作系统管理的资源，包括：网络链接，打开的文件，计时器，同步对象等等。Linux上是文件描述符，Windows上就是Socket或者Handle了，这里统一称为“句柄集”；程序在指定的句柄上注册关心的事件，比如I/O事件。

2）　Event Demultiplexer

　　事件分离器，由操作系统提供，在linux上一般是select,poll,epoll等系统调用，在一个Handle集合上等待事件的发生。接受client连接，建立对应client的事件处理器（Event Handler），并向事件分发器（Reactor）注册此事件处理器（Handler）。

3）　Reactor(Initiation Dispatcher)

　　提供接口：注册，删除和派发Event Handler。Event Demultiplexer等待事件的发生，当检测到新的事件，就把事件交给Initiation Dispatcher，它去回调Event Handler。

4）　Event Handler

　　事件处理器，负责处理特定事件的处理函数。一般在基本的Handler基础上还会有更进一步的层次划分，用来抽象诸如decode，process和encoder这些过程。比如对Web Server而言，decode通常是HTTP请求的解析，process的过程会进一步涉及到Listner和Servlet的调用。为了简化设计，Event Handler通常被设计成状态机，按GoF的state pattern来实现。

5） Concrete Event Handler

　　继承上面的类，实现钩子方法。应用把Concrete Event Handler注册到Reactor，等待被处理的事件。当事件发生，这些方法被回调。

事件处理流程

模式模型

应用场景举例

场景：长途客车在路途上，有人上车有人下车，但是乘客总是希望能够在客车上得到休息。

传统做法：每隔一段时间（或每一个站），司机或售票员对每一个乘客询问是否下车。

Reactor做法：汽车是乘客访问的主体（Reactor），乘客上车后，到售票员（acceptor）处登记，之后乘客便可以休息睡觉去了，当到达乘客所要到达的目的地后，售票员将其唤醒即可。

1) 单线程模型

　　这是最简单的单Reactor单线程模型。Reactor线程是个多面手，负责多路分离套接字，Accept新连接，并分派请求到处理器链中。该模型适用于处理器链中业务处理组件能快速完成的场景。不过这种单线程模型不能充分利用多核资源，所以实际使用的不多。

2) 多线程模型（单Reactor）

　　相比上一种模型，该模型在事件处理器（Handler）链部分采用了多线程（线程池），也是后端程序常用的模型。

3) 多线程模型（多Reactor）

　　这个模型比起第二种模型，它是将Reactor分成两部分，mainReactor负责监听并accept新连接，然后将建立的socket通过多路复用器（Acceptor）分派给subReactor。subReactor负责多路分离已连接的socket，读写网络数据；业务处理功能，其交给worker线程池完成。通常，subReactor个数上可与cpu个数等同。

优缺点

优点

响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
可扩展性，可以方便的通过增加Reactor实例个数来充分利用cpu资源；
可复用性，Reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；

缺点

应用受限制：Reactor模式只能应用在支持Handle的操作系统上。虽然可以使用多线程模拟Reactor，但因为同步控制和上下文切换的要求，这种实现效率低，与Reactor模式出发点相违背。
非抢占模式：在单线程的实现这种情况下，事件的处理必须不能使用阻塞的I/O，因此，如果存在长期操作，比如传输大量的数据。使用主动对象，效率可能更好，主动对象可以并发的处理这些任务。
难以调试：使用Reactor模式的应用程序可能会难以调试，因为程序运行的控制流会在框架和应用相关的处理器之间跳转，不了解框架的应用程序开发人员难一跟着调试。

Reactor模式在DSS中的体现

　　Darwin流媒体服务器是由父进程及其fork出来的子进程构成的，子进程就是核心服务器。父进程的职责就是等待子进程退出。如果子进程出错退出，则父进程就会fork一个新的子进程，从而保证视频服务器继续提供服务。核心服务器的作用是充当VOD(视频点播)客户端与服务器模块之间的接口，VOD客户端采用RTP和RTSP协议向服务器发送请求并接收响应，服务器模块负责处理VOD客户端的请求并向VOD客户端发送数据包。

　　在DSS中，除主线程以外，还有有三种类型的线程：

TaskThread：TaskThread通过运行Task类型对象的Run方法来完成相应Task的处理。典型的Task类型是RTSPSession和RTPSession。TaskThread的个数是可配置的，缺省情况下TaskThread的个数与处理器的个数一致。等待被TaskThread调用并运行的Task放在队列或者堆中。
EventThread：EventThread负责侦听套接口事件，在DSS中，有两种被侦听的事件，分别是建立RTSP连接请求的到达和RTSP请求的到达。对于RTSP连接请求的事件，EventThread建立一个RTSP
Session，并启动针对相应的socket的侦听。对于RTSP请求的事件，EventThread把对应的RTSPSession类型的Task加入到TaskThread的队列中，等待RTSP请求被处理。
IdleTaskThread：IdleTaskThread管理IdleTask类型对象的队列，根据预先设定的定时器触发IdleTask的调度。TCPListenerSocket就是一个IdleTask的派生类，当并发连接数达到设定的最大值时，会把派生自TCPListenerSocket的RTSPListenerSocket加入到IdleTaskThread管理的IdleTask队列中，暂时停止对RTSP端口的侦听，直到被设定好的定时器触发。

下图是DarwinStreaming Server核心架构的示意图。在这个示意图中有三种类型的要素，分别是线程，Task队列或者堆，被侦听的事件。

　　其中，事件线程（Event thread）是Event Demultiplexer（事件分离器），任务线程（Task threads）是Event Handler（事件处理器）。

这里的主线程（Main thread）就是Reactor模式中的Reactor(Initiation Dispatcher)。

原文链接：https://www.f2er.com/react/306399.html

Reactor模式及在DSS中的体现