Reactor模式

Reactor是1995年由道格拉斯提出的一种高性能网络编程模式。由于好多年了，当时的一些概念与现在略有不同，reactor模式在网络编程中是非常重要的，可以说是NIO框架的典型模式，一些经典的框架，比如Mina、Netty、Cindy都是此模式的实现。

我们来看看当年提出的通用模型：

上面的图形中：

1、Handle 可以理解为资源或者文件句柄，放在netty里面就是channel，就是我们实际要处理的东西

2、Event Handler和Concrete Event Handler 就是具体的事件处理器，对应netty中的handler接口和具体的handler

3、Synchronous Event Demultiplexer同步事件多路复用分发器，可以理解为nio中的select

4、Initiation Dispatcher，分发器，可以理解为nio中的循环，也就是netty中的EventLoop，处理各种事件

5、select（handlers）就是真正处理业务的地方

大家注意上面图形中的几个箭头，可以看出各个组件之间的关联关系。这个经典的模型当时并不是针对Java提出的，任何拥有这些组件的语言，都可以实现高性能的reactor模型。

单线程Reactor

基于Java，Doug Lea（Java并发包作者）提出了三种形式，单线程Reactor，多线程Reactor和Multiple Reactor。首先看一下基本的单线程模式：

单线程模型就是一个reactor（select+循环），客户端（client）注册进来由reactor接收注册事件，然后再由reactor分发（dispatch）出去，由下面的处理器（read、decode、compute等）去处理。我们前面复习nio代码的时候，程序就是这样的结构，只有一个select。

多线程Reactor

单线程的Reactor有明显的不足，只有一个线程，又要接收连接，又要处理io读写，还要处理计算和业务逻辑，如果是io密集型还行，如果是计算密集型效率会很慢。现在的机器都是多核的，只用一个线程也浪费机器资源，无法充分利用机器。多线程Reactor能解决这个问题，来看一下多线程Reactor模型：

在多线程Reactor中，注册接收事件都是由Reactor来做，其它的计算，编解码由一个线程池来做。单独一个线程接收请求，另一个线程池处理其它业务。这种模型的问题就是，使用线程池处理的时候，很多地方会有多次线程切换，上下文切换，导致效率比较低，有很多问题要处理，甚至光是接收和读写等请求一个线程也可能忙不过来，因此有了第三种模式，就是Multiple Reactor。

Multiple Reactor

这种模式特点是有多个Reactor，一个boss Reactor负责接收，另外几个worker  Reactor负责读写，把业务部分的处理还是放到线程池中来做。我们前面讨论的netty示例代码其实就是这样的模型：

netty中的handler默认没有启用线程池，如果我们定义用线程池去处理，那么就和上面的模型几乎一模一样了。上面的三种Reactor模式就是最基本的Java的三种Reactor模式。

网上关于Reactor的内容有很多，分的类型也更细一些，扩展了很多其它的形式，针对具体的场景有一些更加详细的模式，比如下面的主从Reactor模式：

在主从Reactor模式中，再次对Reactor进行细分，有一个主要的Reactor进行接收，里面可以做一些认证登录之类的事情，完了之后再分配到Sub Reactor下面去，再做具体的IO处理。

网上关于Reactor模型有很多，但是Java经典的三种最基本的一定要了解清楚，我们设计自己的架构的时候，不要被网上过多的五花八门的模型扰乱，从基本模型触发就可以。

Netty支持的Reactor形式

netty其实对三种Java基本的Reactor模式都是支持的。我们前面演示过，netty启动时，要在ServerBootstrap中配置bossGroup和childGroup两个EventLoopGroup，也就是说netty是可以灵活配置的。我们通过配置可以让netty分别实现对三种模式的支持。

先看一下对单线程reactor的配置：

在配置的时候，boss和worker两个group配置成一个，也就是说两个group的工作交给一个bossGroup（线程数为1）来完成。这样实际上就是第一个单线程reactor的模型。上面的代码就是对第一种模式的支持。

再来看一下对第二种多线程reactor模式的支持，其实第二种模式和第一种代码的配置是一样的，只是在handler中进行处理的时候，使用一个线程池处理所有业务，这样就是第二种多线程的reactor模式。

第三种Multiple Reactor模式是我们用的最多的模式，也是前面例子演示中的配置形式。boss为单线程，worker为多线程，在ServerBootstrap中同时配置boss和worker，下面是我们熟悉的代码：

EventLoopGroup如果没有配置线程数量，默认创建cpu个数的两倍，所以上面worker的线程数根据机器决定。但是现在如果要严格对应第三种模式，在handler中，还要加上线程池。如果计算不太复杂，一个workerGroup就可以了，如果需要很复杂的计算，建议在handler中加入线程池进行处理。尽量不要让IO线程池阻塞。 

在很多netty项目中，还有这样的写法：

boss和worker中的线程数都是多个，这种配置并没有对应前面提过的任何一种模式，那么会有这种需要使用多个boss线程的情况吗？我们知道accept只能保存到一个线程上，所以说bossGroup配置多个是没有用的，所以也有人问netty框架的作者，这种什么时候会用到，下面是作者的回答：

大致是说，这种配置不是必须的，但是它可能会非常有用，比如当多个ServerBootstrap共享一个NioEventLoopGroup的时候会非常有用，意思就是，每个ServerBootstrap都要注册一个NioServerSocketChannel，如图：

如果多个ServerBootstrap都使用一个bossGroup，这时候bossGroup初始化为1个线程，就意味着一个线程监听多个端口，这样显然不太好，这时候bossGroup就可以配置成多个，这样可以每个端口由一个线程去监听，提高效率。

但是，上面是想象中的使用情况，我们实际开发netty的时候，几乎没有看到有多个ServerBootstrap的情况，所以bossGroup配置成多个在现在看来几乎是没有用的，我们把bossGroup的参数直接写成1就可以。即使写成了8，实际执行的时候，也只会用到一个线程，ServerBootstrap只会使用一个，不会使用多个。

关于主从reactor模式，从目前netty看没有办法通过配置直接实现。