网络IO模型以及实际应用

网络IO模型

本文主要介绍了几种不同的网络IO模型，以及实际应用中使用到的Reactor模型等。

我们常说的网络IO模型，主要包含阻塞IO、非阻塞IO、多路复用IO、信号驱动IO、异步IO。在这里插入图片描述

根据第一个阶段：是否需要阻塞，分为阻塞和非阻塞IO。第二个阶段：将数据从内核copy到用户空间，分为同步和异步。这一步如果是操作系统自动完成，是异步。否则是同步。

BIO、NIO、AIO的区别

同步阻塞IO（BIO）：用户进程发起一个IO操作以后，必须等待IO操作的真正完成后，才能继续运行；
同步非阻塞IO（NIO）：用户进程发起一个IO操作以后，可做其它事情，但用户进程需要经常询问IO操作是否完成，这样造成不必要的CPU资源浪费。

异步非阻塞IO（AIO）：用户进程发起一个IO操作然后，立即返回，等IO操作真正的完成以后，应用程序会得到IO操作完成的通知。类比Future模式。

NIO相对于BIO来说一大进步。客户端和服务器之间通过Channel通信。NIO可以在Channel进行读写操作。这些Channel都会被注册在Selector多路复用器上。Selector通过一个线程不停的轮询这些Channel。找出已经准备就绪的Channel执行IO操作。 NIO 通过一个线程轮询，实现千万个客户端的请求，这就是非阻塞NIO的特点
异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理.
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。
AIO 并没有采用NIO的多路复用器，而是使用异步通道的概念。其read，write方法的返回类型都是Future对象。而Future模型是异步的，其核心思想是：去主函数等待时间

IO多路复用

为什么要有这项技术？解决了什么问题？

同步非阻塞，针对每一个用户请求（读、写操作），单独创建一个线程去进行处理（读、写)。线程资源是珍贵和宝贵的。对每一个请求创建一个线程，不合理也非常浪费。因此出现了IO多路技术。
使用单线程处理多个IO操作。只有当其中某一个IO准备就绪后才会进行相应的处理，从而提高程序的效率和并发性。

I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。
有以下几种实现方式：
在这里插入图片描述

异步IO（AIO）

应用进程通知内核开始一个异步I/O操作，并让内核在整个操作（包含将数据从内核复制到应该进程的缓冲区）完成后通知应用进程。实际中很少有应用。

Reactor模型和Proactor模型（实际应用）

无论是C++还是Java编写的网络框架，大多数都是基于Reactor模型进行设计和开发，Reactor模型基于事件驱动，特别适合处理海量的I/O事件。
Reactor模型中定义的三种角色：

Reactor：负责监听和分配事件，将I/O事件分派给对应的Handler。新的事件包含连接建立就绪、读就绪、写就绪等。
Acceptor：处理客户端新连接，并分派请求到处理器链中。
Handler：将自身与事件绑定，执行非阻塞读/写任务，完成channel的读入，完成处理业务逻辑后，负责将结果写出channel。可用资源池来管理。
Reactor处理请求的流程：
读取操作：
应用程序注册读就绪事件和相关联的事件处理器
事件分离器等待事件的发生
当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器

单Reactor单线程模型

Reactor线程负责多路分离套接字，accept新连接，并分派请求到handler。Redis使用单Reactor单进程的模型。
在这里插入图片描述

消息处理流程：

Reactor对象通过select监控连接事件，收到事件后通过dispatch进行转发。
如果是连接建立的事件，则由acceptor接受连接，并创建handler处理后续事件。
如果不是建立连接事件，则Reactor会分发调用Handler来响应。
handler会完成read->业务处理->send的完整业务流程。
单Reactor单线程模型只是在代码上进行了组件的区分，但是整体操作还是单线程，不能充分利用硬件资源。handler业务处理部分没有异步。

对于一些小容量应用场景，可以使用单Reactor单线程模型。但是对于高负载、大并发的应用场景却不合适，主要原因如下：

即便Reactor线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送。
当Reactor线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重Reactor线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈。
一旦Reactor线程意外中断或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。
为了解决这些问题，演进出单Reactor多线程模型。

单Reactor多线程模型

该模型在事件处理器（Handler）部分采用了多线程（线程池）。
在这里插入图片描述
消息处理流程：
Reactor对象通过Select监控客户端请求事件，收到事件后通过dispatch进行分发。
如果是建立连接请求事件，则由acceptor通过accept处理连接请求，然后创建一个Handler对象处理连接完成后续的各种事件。
如果不是建立连接事件，则Reactor会分发调用连接对应的Handler来响应。
Handler只负责响应事件，不做具体业务处理，通过Read读取数据后，会分发给后面的Worker线程池进行业务处理。
Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给Handler进行处理。
Handler收到响应结果后通过send将响应结果返回给Client。
相对于第一种模型来说，在处理业务逻辑，也就是获取到IO的读写事件之后，交由线程池来处理，handler收到响应后通过send将响应结果返回给客户端。这样可以降低Reactor的性能开销，从而更专注的做事件分发工作了，提升整个应用的吞吐。

但是这个模型存在的问题：

多线程数据共享和访问比较复杂。如果子线程完成业务处理后，把结果传递给主线程Reactor进行发送，就会涉及共享数据的互斥和保护机制。
Reactor承担所有事件的监听和响应，只在主线程中运行，可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。
为了解决性能问题，产生了第三种主从Reactor多线程模型。

3.主从Reactor多线程模型**

比起第二种模型，它是将Reactor分成两部分：
在这里插入图片描述

mainReactor负责监听server socket，用来处理网络IO连接建立操作，将建立的socketChannel指定注册给subReactor。
subReactor主要做和建立起来的socket做数据交互和事件业务处理操作。通常，subReactor个数上可与CPU个数等同。
Nginx、Swoole、Memcached和Netty都是采用这种实现。

消息处理流程：

从主线程池中随机选择一个Reactor线程作为acceptor线程，用于绑定监听端口，接收客户端连接
acceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作
步骤2完成之后，业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到Sub线程池的线程上，并创建一个Handler用于处理各种连接事件
当有新的事件发生时，SubReactor会调用连接对应的Handler进行响应
Handler通过Read读取数据后，会分发给后面的Worker线程池进行业务处理
Worker线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给Handler进行处理
Handler收到响应结果后通过Send将响应结果返回给Client
总结
Reactor模型具有如下的优点：

响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
可扩展性，可以方便地通过增加Reactor实例个数来充分利用CPU资源；
可复用性，Reactor模型本身与具体事件处理逻辑无关，具有很高的复用性。