01.前言 · 浅析IO模型
02.图解BIO之传统编程模型
03.基于I/O复用模型的Reactor模式
04.Reactor模式的多样变化
05.最后总结
01.前言 · 浅析IO模型
IO操作，包括网络IO，文件IO。本文讨论的是网络编程中的概念。IO模型的话，很多大佬都做过深入分析，一般分为5种模型。我们这边也不去从LInux系统底层去深度剖析，从下面的IO模型对比图，可以理解区别一下 同步阻塞 这四字中同步和阻塞各自的含义。
如图中所示，其实我们操作IO一般就是分为俩个过程，等待数据就绪，拷贝数据从内核复制到用户空间。前四种模型都是阻塞的，并且第二阶段都是阻塞的。我们可以从下面的概念来理解一下同步、阻塞的概念。
(1).阻塞调用与非阻塞调用
阻塞调用，调用结果返回之前，当前线程会被挂起，一直等待，直到结果返回；
非阻塞调用则不用等调用结果返回，不会阻塞当前线程，可以去干其他事情。
(2).同步处理和异步处理
同步处理是指，被调用方得到最终结果之后返回给调用方；
异步处理是指，被调用方不等处理结束先返回响应，再进行计算，当计算完成时，通知调用方并将结果返回给调用方。
02.图解BIO之传统编程模型
BIO BLockingIO(同步阻塞模式)。当我们调用类似accept(),read(),connect()等API操作时，系统调用会卡住。例如，我们调用read()方法从socket中去读取数据，但是其实我们无法预知对方数据是否发送，只能是一直等待或者网络超时。这是我们传统的阻塞式网络编程，一个线程被挂起，望眼欲穿，什么事情也干不了，干等着。
想想看，要是有个几千几万的连接过来，那么我们得启动对应数量的线程大军，全都hang住，这对操作系统来说是灾难性的。线程越多，Context Switch操作越多，这会消耗大量CPU。
并且每一个线程都会使用一定大小的栈，要是有成千上万的线程，那么内存消耗也是很吓人的，虽然可以通过大内存撑起了上万并发，那百万，千万呢？不过系统稳定性和成本都会指数爆炸。
也有人提出使用线程池去优化，避免产生大量的线程，但是这样做同时也限制了连接数量，这肯定不是最优解，如果是一个对外的TCP服务，网络连接数量是不可预估的。
03.基于I/O复用模型的Reactor模式
当当当~，NIO就要闪亮登场，NON-Blocking，同步非阻塞模式，和BIO的区别是什么呢？
我们同样进行read操作:
BIO一个客户端连接对应一条处理线程，在没有数据过来的时候，read操作就会一直卡在那里；
NIO不是这样子的，一旦调用read()操作就会马上返回，没有数据就会返回-1，有数据就返回读取的字节数。
一般我们会采用I/O多路复用的模型，多个连接共用一个对象，应用程序只需要在一个对象上阻塞住，无需阻塞等待所有的连接。当某条连接有新的数据可以处理的时候，就由系统通知应用程序，阻塞的线程就会唤醒，准备进行业务处理。
这时候不会采用BIO中那种一个连接对应一个线程的方式，我们采用线程池，复用线程资源，将连接完成的业务处理任务分发给线程池中的线程进行处理，一个线程可以处理很多连接的业务。
基于线程池+I/O复用模型，这就是Reactor模式基本设计思想。
Reactor模式，通过一个或者多个输入同时传递给服务端请求的事件驱动处理模式。服务端处理多路请求，将请求分发给请求对应的处理线程。I/O多路复用统一监听多个事件，当接收到事件的时候分发给处理线程。
04.Reactor模式的多样变化
Reactor模式最基本的俩个组件：
- Reactor，反应器，起反应的人，他就像是电话接线员，接听来自各个地方的客户电话并转移到适当的联系人。一般Reactor运行在一个线程或者进程上，负责监听和分发事件，有事件到来，就分发给适当的处理线程去对IO事件做出反应。
- Handlers，操作者，就好比是公司里的业务员。处理执行I/O事件要完成的实际事件，主要是Reactor调度给他，适当地执行非阻塞的操作。
根据Reactor的数量和处理资源线程池的数量不同我们可以有以下三种变化：
1.单Reactor单线程
2.单Reactor多线程
3.主从Reactor多线程
05.最后总结
最后，我们可以总结一下，Reactor模式具有如下的优点：
- 响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的
- 编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销
- 可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源
- 可复用性，Reactor模型本身与具体事件处理逻辑无关，具有很高的复用性
