下面这个图很经典：
1、acceptor接收client事件，并注册到reactor(其实是一个阻塞队列)
2、reactor的selector被注册到上面的事件唤醒，select出多个就绪事件。
3、select出的事件，根据其事件类型，找到对应的事件处理器。由worder线程进行处理
reactor模型
个人感想：
- reactor模型相比传统 one-pre-one-thread模型来看，把请求粒度缩小到事件维度。比如：一个读请求，包含了连接事件，读就绪事件，写就绪事件，还有编码事件，解码事件等等。这样的话，多个读请求，不太可能会同时就绪。因为人操作总有先后，那么线程就能为先就绪的读事件处理。如果是传统IO模型，读未就绪的请求会一直占用一个线程，浪费cpu。
- reactor是事件驱动模型，不是请求驱动，也不是其他驱动。事件是比线程粒度更小的东西，优先服务事件就绪的client，充分利用（其实是压榨）cpu资源。
- 线程的资源是有限的（因为和cpu相关），但是事件的资源几乎无限(因为和内存相关)。cpu资源其实也就几核，几十核，最多也就支持个几百个线程。线程再多的话，就会导致线程间切换开销快速增长，机器整体吞吐量快速下降。但是事件驱动模型就不会，有限个线程支持几乎无限个事件。
- 事件驱动模型也是有缺点的，比如，并发量不小也不大的时候，传统IO模型对请求的响应更加及时，毕竟没有其他请求影响它。但是，reactor模型select多个相同事件的时候，while循环处理，第一个事件对应的请求1就要比最后一个处理的事件对应的请求2，响应的快那么一点点。给client的感觉就是，同时发起的请求，你比我快一些。所以，reactor模型，不适用并发量小且io数据量大的场景(文件下载功能)。
再说说同步阻塞和同步非阻塞（client视角和server视角来说）
- 不管传统BIO模型还是reactor模型，从client视角来看，用户发起请求后连接一直在同步等待数据，无法继续执行自己的业务逻辑（视自己业务而定，也可能不需要关心数据继续执行业务。这里说的是大部分业务情况）。client请求线程会阻塞自己，等待网络io唤醒自己。所以说是同步阻塞。
- 但是从server视角来看，传统BIO模型，一个请求创建一个线程，线程在等待网络IO的请求数据前会阻塞自己，或者线程在等待磁盘IO数据时，也会阻塞自己。并且client请求创建的server的socket channel也在同步等待着。所以说是同步阻塞。
- reactor模型，从server视角来看，server的socket channel也在同步等待着数据，给客户端返回数据。但是线程呢？reactor模型下，线程是事件驱动，一个请求过来了，如果其对应的事件就绪，线程干活。如果事件没有就绪，该线程还可以为其他请求的就绪事件服务。线程并不阻塞，而是忙着做事，充分利用着cpu。所以说是同步非阻塞。
