reactor模式

IO线程模型概述

目前的IO线程处理模型一般可以分为以下三类

1. 单线程阻塞I/O服务模型
2. 多线程阻塞IO服务模型
3. Reactor模式

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

1. 单Reactor单线程
2. 单Reactor多线程
3. 主从Reactor多线程

传统阻塞I/O线程模型

传统阻塞的IO线程线程模型在处理IO事件的时候其实就是不断使用一个循环监听端口是否有新的套接字连接，如果有就进行相应的处理，但是在业务逻辑较为复杂的情况下，无法快速返回进行新的连接操作，会导致后续的连接阻塞，效率太低。其线程模型如下图所示：

(对于多线程阻塞IO这里就不再赘述，就是一个线程对应一个连接)

Reactor模型

针对传统阻塞I/O服务模型的缺点，解决方案一般有两个

1. 基于 I/O 复用模型：多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象等待，无需阻塞等待所有连接。当某个连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。
2. 基于线程池复用线程资源：不必再为每个连接创建线程，将连接完成后的业务处理任务分配给线程进行处理，一个线程可以处理多个连接的业务。

I/O复用结合线程池，就是Reactor模式基本设计思想，如图所示：

单Reactor单线程模式

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

• 性能问题，只有一个线程，无法完全发挥多核 CPU 的性能。Handler 在处理某个连接上的业务时，整个进程无法处理其他连接事件，很容易导致性能瓶颈。
• 可靠性问题，线程意外终止，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障

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

单Reactor多线程模型

优点：可以充分的利用多核cpu 的处理能力
缺点：多线程数据共享和访问比较复杂， reactor 处理所有的事件的监听和响应，在单线程运行， 在高并发场景容易出现性能瓶颈.

主从Reactor多线程模型

优点：父线程与子线程的数据交互简单职责明确，父线程只需要接收新连接，子线程完成后续的业务处理。Reactor 主线程只需要把新连接传给子线程，子线程无需返回数据。
缺点：编程复杂度较高
结合实例：这种模型在许多项目中广泛使用，包括 Nginx 主从 Reactor 多进程模型，Memcached 主从多线程，Netty 主从多线程模型也进行了支持

Netty中的reactor模型

Netty主要是基于主从Reactor多线程模式做了一定的改进，其中主从Reactor都由单线程一个变成了多线程。

Server 端包含 1 个 Boss的NioEventLoopGroup 和 1 个 Worker的NioEventLoopGroup。NioEventLoopGroup 相当于 1 个事件循环组，这个组里包含多个事件循环 NioEventLoop，每个 NioEventLoop 包含 1 个 Selector 和 1 个事件循环线程。每个Boss的NioEventLoop循环执行的任务包含 3 步：

1. 轮询 Accept 事件；
2. 处理 Accept I/O 事件，与 Client 建立连接，生成 NioSocketChannel，并将 NioSocketChannel 注册到某个 Worker NioEventLoop 的 Selector 上；
3. 处理任务队列中的任务，runAllTasks。任务队列中的任务包括用户调用eventloop.execute或schedule执行的任务，或者其他线程提交到该eventloop的任务。

每个 Worker NioEventLoop 循环执行的任务包含 3 步：

1. 轮询 Read、Write 事件；
2. 处理 I/O 事件，即 Read、Write 事件，在 NioSocketChannel 可读、可写事件发生时进行处理；
3. 处理任务队列中的任务，runAllTasks。

其中任务队列中的 Task 有 3 种典型使用场景：
1、用户程序自定义的普通任务：

ctx.channel().eventLoop().execute(newRunnable() {
   @Override
   public void run() {
       //执行的任务逻辑
   }
});

2、非当前 Reactor 线程调用 Channel 的各种方法

例如在推送系统的业务线程里面，根据用户的标识，找到对应的 Channel 引用，然后调用 Write 类方法向该用户推送消息，就会进入到这种场景。最终的 Write 会提交到任务队列中后被异步消费。

3、用户自定义定时任务

ctx.channel().eventLoop().schedule(newRunnable() {
   @Override
   public void run() {
     //执行的任务逻辑
   }
}, 60, TimeUnit.SECONDS);