Reactor反应器模式
Reactor反应器模式
反应器模式由Reactor反应器线程、Handlers处理器两大角色组成:
- Reactor反应器线程的职责:负责响应IO事件,并且分发到Handlers处理器。负责查询IO事件,当检测到一个IO事件,将其发送给相应的Handler处理器去处理。这里的IO事件,就是NIO中选择器监控的通道IO事件。
- Handlers处理器的职责:非阻塞的执行业务处理逻辑。与IO事件(或者选择键)绑定,负责IO事件的处理。完成真正的连接建立、通道的读取、处理业务逻辑、负责将结果写出到通道等。
OIO中用创建一个线程处理一个连接请求(Connection Per Thread),这样在一个业务没有处理完时不会阻塞其他请求的接收。但是频繁创建销毁切换线程有很大的代价,耗费大量的线程资源。
单线程版Reactor:
单线程处理事件监听并在同一个线程中处理业务数据。所以一旦某个handler业务阻塞,则其他所以的handler都无法得到执行。单线程模型也无法充分利用系统多核资源。
多线程的Reactor反应器:
升级Handler处理器,使用线程池。多线程,又要尽可能的高效率。
升级Reactor反应器,引入多个Selector选择器,提升选择大量通道的能力。
业务处理线程与负责服务监听和IO事件查询的反应器线程相隔离,避免服务器的连接监听受到阻塞。如果多核的CPU,可将反应器线程拆分为多个子反应器(SubReactor)线程。
反应器模式的优点和缺点:
优点
响应快,虽然同一反应器线程本身是同步的,但不会被单个连接的同步IO所阻塞;
编程相对简单,最大程度避免了复杂的多线程同步,也避免了多线程的各个进程之间切换的开销;
可扩展,可以方便地通过增加反应器线程的个数来充分利用CPU资源。
缺点
反应器模式增加了一定的复杂性,因而有一定的门槛,并且不易于调试。
反应器模式需要操作系统底层的IO多路复用的支持,如Linux中的epoll。如果操作系统的底层不支持IO多路复用,反应器模式不会有那么高效。
同一个Handler业务线程中,如果出现一个长时间的数据读写,会影响这个反应器中其他通道的IO处理。
充分利用系统资源,最大限度减少阻塞。
反应器模式与生产者消费者
反应器模式与观察着模式
代码整理
时间换空间,空间换时间
阅读笔记 《Netty、Redis、Zookeeper高并发实战》
梦想与现实,努力吧。