Library
redisread opened this issue · comments
knowledge
Reactor模型
在高性能的I/O设计中，有两个著名的模型：Reactor模型和Proactor模型，其中Reactor模型用于同步I/O，而Proactor模型运用于异步I/O操作。
IO是Input/Output的缩写。Unix网络编程中有五种IO模型：
blocking IO（阻塞IO）
nonblocking IO（非阻塞IO）
IO multiplexing（多路复用IO）
signal driven IO（信号驱动IO）
asynchronous IO（异步IO）
BIO
在读取输入流或者写入输出流时，在读、写动作完成之前，线程会一直阻塞。
传统的服务器端同步阻塞I/O处理（也就是BIO，Blocking I/O）的经典编程模型。
这个模型严重依赖于线程，但线程是很”贵”的资源，主要表现在：
线程的创建和销毁成本很高，在Linux这样的操作系统中，线程本质上就是一个进程。创建和销毁都是重量级的系统函数。
线程本身占用较大内存，像Java的线程栈，一般至少分配512K～1M的空间，如果系统中的线程数过千，占用的内存将非常惊人。
线程的切换成本是很高的。操作系统发生线程切换的时候，需要保留线程的上下文，然后执行系统调用。如果线程数过高，可能执行线程切换的时间甚至会大于线程执行的时间，这时候带来的表现往往是系统load偏高、CPU sy使用率特别高（超过20%以上)，导致系统几乎陷入不可用的状态。
容易造成锯齿状的系统负载。因为系统负载是用活动线程数或CPU核心数，一旦线程数量高而且外部网络环境不是很稳定，就很容易造成大量请求的结果同时返回，激活大量阻塞线程从而使系统负载压力过大。
所以，当面对十万甚至百万级连接的时候，传统的BIO模型是无能为力的。随着移动端应用的兴起和各种网络游戏的盛行，百万级长连接日趋普遍，此时，NIO技术应运而生。
NIO
基于事件驱动**，采用reactor（反应器）模式。当发起IO请求时，应用程序是非阻塞的。当SOCKET有流可读或写的时候，由操作系统通知应用程序，应用程序再将流读取到缓冲区或者写入系统。
AIO
同样基于事件驱动的**，通常采用Proactor(前摄器模式)实现。在进行I/O操作时，直接调用API的read或write，这两种方法均为异步。对于读操作，操作系统将数据读到缓冲区，并通知应用程序，对于写操作，操作系统将write方法传递的流写入并主动通知应用程序。它节省了NIO中select函数遍历事件通知队列的代价(红黑树遍历)。
同步异步模式
半同步/半异步模式
单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。
主从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