Reactor线程模型！

核心组成

Reactor：

• Reactor 在一个单独的线程中运行，负责监听和分发事件
  • 分发给适当的处理程序来对 IO 事件做出反应。

Handlers：

• 处理程序执行 I/O 事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际官员。
  • Reactor 通过调度适当的处理程序来响应 I/O 事件，处理程序执行非阻塞操作。

模式分类

根据 Reactor 的数量和处理资源池线程的数量不同，有 3 种典型的实现：

• 单 Reactor 单线程
• 单 Reactor 多线程
• 主从 Reactor 多线程

单 Reactor 单线程

Select 实现应用程序通过一个阻塞对象监听多路连接请求

Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 Dispatch 进行分发

如果是建立连接请求事件，则由 Acceptor 通过 Accept 处理连接请求

• 然后创建一个Handler 对象处理连接完成后的后续业务处理

如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应

Handler 会完成 Read ==> 业务处理 ==> Send 的完整业务流程

服务器端用 一个线程 通过 多路复用 搞定所有的 IO 操作（包括连接，读、写等），编码简单，清晰明了

• 但是如果客户端连接数量较多，将无法支撑，前面的NIO案例就属于这种模型。

优点：

模型简单，没有多线程、进程通信、竞争的问题，全部都在一个线程中完成

缺点：

性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。

• Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈

可靠性问题，线程意外终止，或者进入死循环

• 会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

使用场景：

• 客户端的数量有限，业务处理非常快速，比如 Redis在业务处理的时间复杂度 O(1) 的情况。

单 Reactor 多线程

Reactor 对象通过 select 监控客户端请求事件, 收到事件后，通过dispatch进行分发

如果建立连接请求, 则右 Acceptor 通过 accept 处理连接请求

• 然后创建一个Handler对象处理完成连接后的各种事件

如果不是连接请求，则由reactor分发调用连接对应的 handler 来处理

handler 只负责响应事件，不做具体的业务处理，通过read 读取数据后

• 会分发给后面的worker线程池的某个线程处理业务

worker 线程池 会分配独立线程完成真正的业务，并将结果返回给handler

handler收到响应后，通过send 将结果返回给 client

优点：

• 可以充分的利用多核cpu 的处理能力。

缺点：

• 多线程数据共享和访问比较复杂，reactor 处理所有的事件的监听和响应
• 在单线程运行， 在高并发场景容易出现性能瓶颈。

主从 Reactor 多线程

针对单 Reactor 多线程模型中，Reactor 在单线程中运行

• 高并发场景下容易成为性能瓶颈，可以让 Reactor 在多线程中运行。

Reactor主线程 MainReactor 对象通过 select 监听连接事件

• 收到事件后，通过 Acceptor 处理连接事件

当 Acceptor 处理连接事件后，MainReactor 将连接分配给SubReactor

SubReactor 将连接加入到连接队列进行监听，并创建handler进行各种事件处理

当有新事件发生时，subreactor 就会调用对应的 handler 处理

handler 通过 read 读取数据，分发给后面的worker 线程处理

worker 线程池分配独立的 worker 线程进行业务处理，并返回结果

优点

• 父线程与子线程的数据交互简单职责明确

  • 父线程只需要接收新连接，子线程完成后续的业务处理。

• 父线程与子线程的数据交互简单

  • Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据。

缺点：

• 编程复杂度较高

结合实例：

这种模型在许多项目中广泛使用:

• 包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型的支持