Reactor反应器模式(二)

Reactor反应器模式(二)

文章发布于 2020-08-28 19:31:22,最后更新于 2020-09-08 16:11:58

学习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)的响应时间。因而对于这种操作,还需要进一步对反应器模式进行改进。

Copyright: 采用 知识共享署名4.0 国际许可协议进行许可

Links: https://mxyblogs.club/archives/reactor2

Buy me a cup of coffee ☕.