传统阻塞I/O模式
其中黄色框表示对象,蓝色框表示线程,白色框表示API方法
特点
- 采用阻塞IO模式获取输入数据
- 每个连接都需要独立的线程完成数据的输入,业务处理和处理结果数据返回
潜在问题
- 并发数很大时,需要对应每个连接请求创建一个线程,所以占用资源很大
- 连接创建后,若当前下线程暂时没有数据操作时,该线程会在操作方法处阻塞,造成线程资源浪费
Reactor模式(Dispatch模式)
针对传统阻塞I/O模式的潜在问题,解决方案如下
- 基于I/O复用模型解决创建线程数量多的问题：通过一个阻塞对象管理所有连接
- 基于线程池解决线程资源浪费问题
Reactor模式的设计思想就是I/O复用结合下线程池。
核心组成
- Reator：Reactor在一个单独的thread中运行,负责监听和分发事件,分发给适当的处理程序对IO事件做出反应
- Handler：真正处理执行Reactor分发过来的IO事件
优势
- 响应快：不会由于单个同步而导致阻塞
- 扩展性好：通过方便的增加Reactor实例个数充分利用多核CPU资源
- 复用性好：Reactor本身与具体的事件处理逻辑无关,具有很高的复用性
根据Reactor的数量和处理资源池线程的数量不同,包括单Reactor单线程、单Reactor多线程和主从Reactor多线程
单Reactor单线程
执行流程
- Reactor通过Select监控客户端请求事件,收到事件后通过Dispatch进行分发
- 如果是建立连接请求则由Acceptor处理,并且创建Handler对象处理连接完成后的业务
- 若不是连接请求(比如read)则分发调用对应的Handler来响应(read->业务处理->send流程)
方案分析
- 模式简单,没有多线程竞争,全部由一个线程完成
- 性能问题：仅一个线程,无法发挥多核CPU性能
- 可靠性问题：线程意外终止或者遇到死循环会导致系统不可用
- 适用于客户端数量有限,业务处理非常快速的场景
单Reactor多线程
执行流程
- Reactor通过Select监控客户端请求事件,收到事件后通过Dispatch进行分发
- 如果是建立连接请求则由Acceptor处理,并且创建Handler对象处理连接完成后的业务
- 若不是连接请求(比如read)则Reactor分发调用对应的Handler进行响应(read->分发任务->send流程)
- Handler只负责响应事件,不做具体业务处理,通过read读取数据会分发给work线程池的某个线程处理业务
- work线程池会分配独立线程完成真正的业务并将结果返回给Handler
- Handler收到响应后通过send将结果返回给client
方案分析
- 可以充分利用多核CPU的处理能力
- 多线程数据共享和访问比较复杂,reactor处理所有的事件的监听和响应,在单线程、高并发场景下容易出现性能瓶颈
主从Reactor多线程(Netty基于此模式)
执行流程
- Reactor主线程MainReactor对象通过select监听连接事件,若收到连接请求事件则会通过Acceptor处理
- 当Acceptor处理完成连接事件后,MainReactor将连接分配给SubReactor(一个MainReactor存在多个子Reactor)
- SubReactor将连接加入到连接队列进行监听,并创建Handler进行对应事件处理
- 当存在新事件发生时,subReactor就会调用对应Handler处理
- Handler只负责响应事件,不做具体业务处理,通过read读取数据会分发给work线程池的某个线程处理业务
- work线程池会分配独立线程完成真正的业务并将结果返回给Handler
- Handler收到响应后通过send将结果返回给client
方案分析
- 主线程和子线程数据交互简单职责明确,主线程负责接收连接,子线程完成后续业务处理
- 主线程和子线程交互简单,主线程把连接交给子线程，子线程无需返回数据
- 但编程复杂度比较高
- 应用于Nginx主从Reactor多进程模型、Memcached主从多线程、Netty主从多线程
