Reactor简介
Reactor是一个基础库，用在构建实时数据流应用、要求有容错和低延迟至毫秒、纳秒、皮秒的服务。
高效的含义是什么呢？
传递一个消息从A到B时GC产生的内存很小或者完全没有。
当消费者处理消息的速度低于生产者产生消息的速度时产生了溢出时，必须尽快处理。
尽可能的提供无锁的异步流。
The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers
反应器提供了一个框架，可以帮助你减轻恶心的延迟引起的副作用，在应用程序中使用最小的开销：使用一些灵活的结构，通过在启动时预先分配在运行时的分配数据结构来避免分配问题。
限制主消息传送结构，因而不会导致任务无限的累积。
利用流行的模式例如Reactive和事件驱动架构来提供一个包含应答的非阻塞的、端对端流。
实现了最新的Reactive流标准，通过不发送多于当前容量的请求来使受限的结构更有效率。
使用这些概念到进程间通信，提供了理解控制流的非阻塞IO驱动。
对开发者暴露功能API，帮助开发者使用一个无副作用的方式组织代码，也帮助你确定在什么场景下你是线程安全和具有容错性的。
Structure
1)Resources: Any resource that can provide input to or consume output from the system.
2)Synchronous Event Demultiplexer: Uses an event loop to block on all resources. The demultiplexer sends the resource to the dispatcher when it is possible to start a synchronous operation on a resource without blocking (Example: a synchronous call to read() will block if there is no data to read. The demultiplexer uses select() on the resource,which blocks until the resource is available for reading. In this case,a synchronous call to read() won't block,and the demultiplexer can send the resource to the dispatcher.)
3)Dispatcher: Handles registering and unregistering of request handlers. Dispatches resources from the demultiplexer to the associated request handler.
4)Request Handler: An application defined request handler and its associated resource.
Reactor模式的缺点
Reactor模式的缺点貌似也是显而易见的：
1. 相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
2. Reactor模式需要底层的Synchronous Event Demultiplexer支持，比如Java中的Selector支持，操作系统的select系统调用支持，如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效。
3. Reactor模式在IO读写数据时还是在同一个线程中实现的，即使使用多个Reactor机制的情况下，那些共享一个Reactor的Channel如果出现一个长时间的数据读写，会影响这个Reactor中其他Channel的相应时间，比如在大文件传输时，IO操作就会影响其他Client的相应时间，因而对这种操作，使用传统的Thread-Per-Connection或许是一个更好的选择，或则此时使用Proactor模式。