20220505java学习笔记-----Reactor

Reactor模式

（1）Reactor线程的职责：负责响应IO事件，并且分发到Handlers处理器。

（2）Handlers处理器的职责：非阻塞的执行业务处理逻辑。

多线程OIO的致命缺陷

如果前一个网络连接的handle(socket)没有处理完，那么后面的新连接无法被服务端接收，于是后面的请求就会被阻塞，导致服务器的吞吐量太低。这对于服务器来说是一个严重的问题。

为了解决这个严重的连接阻塞问题，出现了一个极为经典的模式：Connection Per Thread（一个线程处理一个连接）模式，但需要消耗大量资源。

单线程Reactor模式

Reactor和Handlers处于一个线程中执行。

（1）Reactor：负责查询IO事件，当检测到一个IO事件时将其发送给相应的Handler处理器去处理。这里的IO事件就是NIO中选择器查询出来的通道IO事件。

（2）Handler：与IO事件（或者选择键）绑定，负责IO事件的处理，完成真正的连接建立、通道的读取、处理业务逻辑、负责将结果写到通道等。

 

（1）void attach(Object o)：将对象附加到选择键。此方法可以将任何Java POJO对象作为附件添加到SelectionKey实例。

（2）Object attachment()：从选择键获取附加对象。此方法与attach(Object o)是配套使用的，其作用是取出之前通过attach(Object o)方法添加到SelectionKey实例的附加对象。

总结:

 在Reactor模式中，需要将attach和attachment结合使用：在选择键注册完成之后调用attach()方法，将Handler实例绑定到选择键；当IO事件发生时调用attachment()方法，可以从选择键将被select方法查询出来，可以直接将选择键的附件对象取出Handler实例，将事件分发到Handler处理器中完成业务处理。

缺点:

当其中某个Handler阻塞时，会导致其他所有的Handler都得不到执行。在这种场景下，被阻塞的Handler不仅仅负责输入和输出处理的传输处理器，还包括负责新连接监听的AcceptorHandler处理器，可能导致服务器无响应。这是一个非常严重的缺陷，导致单线程反应器模型在生产场景中使用得比较少。除此之外，目前的服务器都是多核的，单线程Reactor模式模型不能充分利用多核资源。总之，在高性能服务器应用场景中，单线程Reactor模式实际使用的很少。 

多线程Reactor模式

（1）将负责数据传输处理的IOHandler处理器的执行放入独立的线程池中。这样，业务处理线程与负责新连接监听的反应器线程就能相互隔离，避免服务器的连接监听受到阻塞。

（2）如果服务器为多核的CPU，可以将反应器线程拆分为多个子反应器（SubReactor）线程；同时，引入多个选择器，并且为每一个SubReactor引入一个线程，一个线程负责一个选择器的事件轮询。这样充分释放了系统资源的能力，也大大提升了反应器管理大量连接或者监听大量传输通道的能力。

Reactor模式和生产者消费者模式对比 

二者的相似之处：在一定程度上，Reactor模式有点类似生产者消费者模式。在生产者消费者模式中，一个或多个生产者将事件加入一个队列中，一个或多个消费者主动从这个队列中拉取（Pull）事件来处理。

二者的不同之处：Reactor模式是基于查询的，没有专门的队列去缓冲存储IO事件，查询到IO事件之后，反应器会根据不同IO选择键（事件）将其分发给对应的Handler来处理。

Reactor模式和观察者模式对比 

二者的相似之处：在Reactor模式中，当查询到IO事件后，服务处理程序使用单路/多路分发（Dispatch）策略，同步分发这些IO事件。

观察者模式（Observer Pattern）也被称作发布/订阅模式，它定义了一种依赖关系，让多个观察者同时监听某一个主题（Topic）。这个主题对象在状态发生变化时会通知所有观察者，它们能够执行相应的处理。

二者的不同之处：在Reactor模式中，Handler实例和IO事件（选择键）的订阅关系基本上是一个事件绑定到一个Handler，每一个IO事件（选择键）被查询后，反应器会将事件分发给所绑定的Handler，也就是一个事件只能被一个Handler处理；在观察者模式中，同一时刻、同一主题可以被订阅过的多个观察者处理。

 Reactor优点

响应快，虽然同一反应器线程本身是同步的，但是不会被单个连接的IO *** 作所阻塞。

编程相对简单，最大限度避免了复杂的多线程同步，也避免了多线程各个进程之间切换的开销。

可扩展，可以方便地通过增加反应器线程的个数来充分利用CPU资源。

  Reactor缺点

 Reactor模式增加了一定的复杂性，因而有一定的门槛，并且不易于调试。

Reactor模式依赖于 *** 作系统底层的IO多路复用系统调用的支持，如Linux中的epoll系统调用。如果 *** 作系统的底层不支持IO多路复用，Reactor模式不会那么高效。

在同一个Handler业务线程中，如果出现一个长时间的数据读写，就会影响这个反应器中其他通道的IO处理。例如，在大文件传输时，IO *** 作就会影响其他客户端的响应时间。对于这种 *** 作，还需要进一步对Reactor模式进行改进。