转自思否用户@郭艺宾

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,一个bossReactor负责接收,另外几个workerReactor负责读写,把业务部分的处理还是放到线程池中来做。我们前面讨论的netty示例代码其实就是这样的模型:
  • netty中的handler默认没有启用线程池,如果我们定义用线程池去处理,那么就和上面的模型几乎一模一样了。上面的三种Reactor模式就是最基本的Java的三种Reactor模式。
  • 网上关于Reactor的内容有很多,分的类型也更细一些,扩展了很多其它的形式,针对具体的场景有一些更加详细的模式,比如下面的主从Reactor模式:
  • 在主从Reactor模式中,再次对Reactor进行细分,有一个主要的Reactor进行接收,里面可以做一些认证登录之类的事情,完了之后再分配到SubReactor下面去,再做具体的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看没有办法通过配置直接实现。