学习Reactor反应器模式(二)

前面学习了单线程的Reactor反应器模式，我接着将单线程的代码改成了多线程。

多线程Reactor反应器模式

总体来说，多线程池反应器的模式，大致如下：

（1）将负责输入输出处理的IOHandler处理器的执行，放入独立的线程池中。这样，业务处理线程与负责服务监听和IO事件查询的反应器线程相隔离，避免服务器的连接监听受到阻塞。

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

代码如下

接下来再看看处理器的代码

class MultiThreadEchoHandler implements Runnable
{
    final SocketChannel channel;
    final SelectionKey sk;
    final ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
    static final int RECIEVING = 0, SENDING = 1;
    int state = RECIEVING;
    //引入线程池
    static ExecutorService pool = Executors.newFixedThreadPool(4);

    MultiThreadEchoHandler(Selector selector, SocketChannel c) throws IOException
    {
        channel = c;
        c.configureBlocking(false);
        //先取得选择键，再设置感兴趣的IO事件
        sk = channel.register(selector, 0);
        //将本Handler作为sk选择键的附件，方便事件dispatch
        sk.attach(this);
        //向sk选择键注册Read就绪事件
        sk.interestOps(SelectionKey.OP_READ);
        selector.wakeup();
    }

    public void run()
    {
        //提交数据传输任务到线程池
        // IO处理不在IO事件轮询线程中执行，在独立的线程池中执行
        pool.submit(()->asyncRun());
    }

    //数据传输任务，不在IO事件轮询线程中执行，在独立的线程池中执行
    public synchronized void asyncRun()
    {
        try
        {
            if (state == SENDING)
            {
                //写入通道
                channel.write(byteBuffer);
                //写完后,准备开始从通道读,byteBuffer切换成写模式
                byteBuffer.clear();
                //写完后,注册read就绪事件
                sk.interestOps(SelectionKey.OP_READ);
                //写完后,进入接收的状态
                state = RECIEVING;
            } else if (state == RECIEVING)
            {
                //从通道读
                int length = 0;
                while ((length = channel.read(byteBuffer)) > 0)
                {
                    Logger.info(new String(byteBuffer.array(), 0, length));
                }
                //读完后，准备开始写入通道,byteBuffer切换成读模式
                byteBuffer.flip();
                //读完后，注册write就绪事件
                sk.interestOps(SelectionKey.OP_WRITE);
                //读完后,进入发送的状态
                state = SENDING;
            }
            //处理结束了, 这里不能关闭select key，需要重复使用
            //sk.cancel();
        } catch (IOException ex)
        {
            ex.printStackTrace();
        }
    }


}

总结

1．反应器模式和生产者消费者模式对比

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

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

2．反应器模式和观察者模式（Observer Pattern）对比

相似之处在于：在反应器模式中，当查询到IO事件后，服务处理程序使用单路/多路分发（Dispatch）策略，同步地分发这些IO事件。观察者模式（ObserverPattern）也被称作发布/订阅模式，它定义了一种依赖关系，让多个观察者同时监听某一个主题（Topic）。这个主题对象在状态发生变化时，会通知所有观察者，它们能够执行相应的处理。

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

最后，总结一下反应器模式的优点和缺点。

作为高性能的IO模式，反应器模式的优点如下：

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

编程相对简单，最大程度避免了复杂的多线程同步，也避免了多线程的各个进程之间切换的开销；· 可扩展，可以方便地通过增加反应器线程的个数来充分利用CPU资源。

反应器模式的缺点如下：

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

反应器模式需要操作系统底层的IO多路复用的支持，如Linux中的epoll。如果操作系统的底层不支持IO多路复用，反应器模式不会有那么高效。

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