Unix/Linux编程：图解 Reactor 和 Proactor

Myth丶恋晨 2022-09-12 05:55 168阅读 0赞

!\[!\[\](https://img-blog.csdnimg.cn/f6a66a6e982a4674bf12a70d0605fbbb.png?x-oss-process=image/watermark,type\_ZHJvaWRzYW5zZmFsbGJhY2s,shadow\_50,text\_Q1NETiBAT2NlYW4mJlN0YXI=,size\_20,color\_FFFFFF,t\_70,g\_se,x\_16)

# 演进 #

如果要让服务器服务多个客户端，那么最直接的方式就是为每一条连接创建线程

其实创建进程也是可以的，原理是一样的，进程和线程的区别在于线程比较轻量级些，线程的创建和线程将切换的成本要小写，为了简便描述，后面都以线程为例

处理完业务逻辑后，随着连接关闭后线程也同样要销毁了，但是这样不停地创建和销毁线程，不仅会带来性能开销，也会造成浪费资源，而且如果要连接几万条连接，创建几万个线程去应对也是不现实的。

要怎么解决这个问题呢？我们可以使用**资源复用**的关系

也就是**不用再为每个连接创建线程，而是创建一个“线程池”，将连接分配给线程，然后一个线程可以处理多个连接的业务**。

不过，这样又引来了一个新的问题，线程怎样才能高效的处理多个连接的业务？

当一个连接对应一个线程时，线程一般采用【read-业务处理-send】的处理流程，如果当前连接没有数据可读，那么线程就会阻塞在`read`操作上（socket默认情况是阻塞IO），不过这样阻塞方式并不影响其他线程。

但是引入了线程池，那么一个线程要处理多个连接的业务，线程在处理某个连接的read操作时，如果没有数据可读，就会发送阻塞，那么线程就没有办法继续处理其他连接的业务。

要解决这一个问题，最简单的方法就是将socket改成非阻塞，然后线程不断的轮询调用read操作来判断是否有数据，这种方式虽然能够解决阻塞的问题，但是解决的方式比较粗暴，因为轮询是要消耗 CPU 的，而且随着一个 线程处理的连接越多，轮询的效率就会越低。

上面的问题在于，线程并不知道当前连接是否有数据可读，从而需要每次通过 read 去试探。

那有没有办法在只有当连接上有数据的时候，线程才去发起读请求呢？答案是有的，实现这一技术的就是 I/O 多路复用。

IO多路复用技术会用一个系统调用函数来监听我们所有关心的连接，也就是说可以在一个监控线程里面监控很多的连接。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16]

我们熟悉的 select/poll/epoll 就是内核提供给用户态的多路复用系统调用，线程可以通过一个系统调用函数从内核中获取多个事件。

select/poll/epoll是一获得网络事件的呢？

在**获取事件时，先把我们要关心的连接传给内核，再由内核检测**

*  **如果没有事件发生，线程只需要阻塞在这个系统调用**，而无需像前面的线程池方案那样轮询调用read操作来判断是否有数据
 *  **如果有事件发生，内核会返回产生了事件的连接，线程就会从阻塞状态返回，然后在用户态中再处理这些连接对应的业务即可**

当下开源软件能够做到网络高性能的原因就是IO多路复用吗？

是的，基本是基于 I/O 多路复用，用过 I/O 多路复用接口写网络程序的同学，肯定知道是面向过程的方式写代码的，这样的开发的效率不高。

于是，大佬们基于面向对象的思想，对 I/O 多路复用作了一层封装，让使用者不用考虑底层网络 API 的细节，只需要关注应用代码的编写。

大佬们还为这种模式取了个让人第一时间难以理解的名字：Reactor 模式。

Reactor 翻译过来的意思是「反应堆」，可能大家会联想到物理学里的核反应堆，实际上并不是的这个意思。

这里的反应值得是**对事件反应**，也就是**来了一个事件，Reactor就有相对应的反应/响应**

实际上，Reactor 模式也叫 Dispatcher 模式，我觉得这个名字更贴合该模式的含义，即**IO多路复用监听事件，收到事件后，根据事件类型分配给某个线程/进程**

Reactor模式主要由Reactor和处理资源池这两个核心部分组成，它俩负责的事情如下：

*  Reactor负责监听和分发事件，事件类型包含连接事件、读写事件
 *  处理资源池负责处理事件，如read->业务逻辑->send

Reactor模式是灵活多变的，可以应对不同的业务场景，灵活在于：

*  Reactor 的数量可以只有一个，也可以有多个；
 *  处理资源池可以是单个进程 / 线程，也可以是多个进程 /线程；
 *  单 Reactor 单进程 / 线程；
 *  单 Reactor 多进程 / 线程；
 *  多 Reactor 单进程 / 线程；
 *  多 Reactor 多进程 / 线程；

其中，「多 Reactor 单进程 / 线程」实现方案相比「单 Reactor 单进程 / 线程」方案，不仅复杂而且也没有性能优势，因此实际中并没有应用。

剩下的 3 个方案都是比较经典的，且都有应用在实际的项目中：

*  单 Reactor 单进程 / 线程；
 *  单 Reactor 多线程 / 进程；
 *  多 Reactor 多进程 / 线程；

方案具体使用进程还是线程，要看使用的编程语言以及平台有关：

*  Java 语言一般使用线程，比如 Netty;
 *  C 语言使用进程和线程都可以，例如 Nginx 使用的是进程，Memcache 使用的是线程。

接下来，分别介绍这三个经典的 Reactor 方案。

# Reactor #

## 单 Reactor 单进程 / 线程 ##

一般来说，C语言实现的是**单Reactor单进程**的方案，因为C语言编写完的程序，运行后就是一个独立的进程，不需要在进程中在创建线程

而Java语言实现的是**单Reactor单线程**的方案，因为Java程序是泡在Java虚拟机这个进程上面的，虚拟机中有很多线程，我们写的Java只是其中一个线程而已

我们来看看「单 Reactor 单进程」的方案示意图：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]  
可以看到进程里有 Reactor、Acceptor、Handler 这三个对象：

*  Reactor对象的作用是监听和分发事件
 *  Accept对象的作用是获取连接
 *  Handle对象的作用是处理业务

对象里的select、accept、read、send是系统调用，dispatch和业务处理是需要完成的操作，其中dispatch是分发事件操作。

接下来，介绍下【单Reactor单进程】这个方案

*  Reactor 对象通过 select （IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；
 *  如果是连接建立的事件，则交给Acceptor对象进行处理，Acceptor 对象会通过accept分发获取连接，并创建一个Handle对象来处理后继的响应事件
 *  如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；
 *  Handler对象通过read->业务处理->send的流程来完成完整的业务流程

单 Reactor 单进程的方案因为全部工作都在同一个进程内完成，所以实现起来比较简单，不需要考虑进程间通信，也不用担心多进程竞争。

但是，这种方案存在 2 个缺点：

*  第一个缺点，因为只有一个进程，无法充分利用多核CPU的性能
 *  第二个缺点，**Handler 对象在业务处理时，整个进程是无法处理其他连接的事件的，如果业务处理耗时比较长，那么就造成响应的延迟；**

所以，**单 Reactor 单进程的方案不适用计算机密集型的场景，只适用于业务处理非常快速的场景**。

Redis 是由 C 语言实现的，它采用的正是「单 Reactor 单进程」的方案，因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上，所以 Redis 对于命令的处理是单进程的方案。

## 单 Reactor 多线程 / 多进程 ##

如果要克服「单 Reactor 单线程 / 进程」方案的缺点，那么就需要引入多线程 / 多进程，这样就产生了单 Reactor 多线程 / 多进程的方案。

「单 Reactor 多线程」方案的示意图如下：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
详细说一下这个方案：

*  Reactor 对象通过 select （IO 多路复用接口） 监听事件，收到事件后通过 dispatch 进行分发，具体分发给 Acceptor 对象还是 Handler 对象，还要看收到的事件类型；
 *  如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
 *  如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；

上面的三个步骤和单Reactor单线程方案是一样的，接下来的步骤就开始不一样了

*  Handler 对象不再负责业务处理，只负责数据的接收和发送，Handler 对象通过 read 读取到数据后，会将数据发给子线程里的 Processor 对象进行业务处理；
 *  子线程里的 Processor 对象就进行业务处理，处理完后，将结果发给主线程中的 Handler 对象，接着由 Handler 通过 send 方法将响应结果发送给 client；

单 Reator 多线程的方案优势在于能够充分利用多核 CPU 的能，那既然引入多线程，那么自然就带来了多线程竞争资源的问题。

比如，子线程完成业务处理后，要把结果传递给主线程的Reactor进行发送，这里涉及到共享数据的竞争。

要避免多线程由于竞争共享资源而导致数据错乱的问题，就需要在操作共享资源前加上互斥锁，以保证任意时间里只有一个线程在操作共享资源，待该线程操作完释放互斥锁后，其他线程才有机会操作共享数据。

聊完单 Reactor 多线程的方案，接着来看看单 Reactor 多进程的方案。

事实上，单 Reactor 多进程相比单 Reactor 多线程实现起来很麻烦，主要因为要考虑子进程 <-> 父进程的双向通信，并且父进程还得知道子进程要将数据发送给哪个客户端。

而多线程间可以共享数据，虽然要额外考虑并发问题，但是这远比进程间通信的复杂度低得多，因此实际应用中也看不到单 Reactor 多进程的模式。

另外，【单Reactor】的模式还有个问题，因为**一个Reactor对象承担所有事件的监听和响应，而且只能在主线程中运行，在面对瞬间高并发的场景时，容易成为性能的瓶颈的地方**

## 多 Reactor 多进程 / 线程 ##

要解决【单Reactor】的问题，就是将【单Reactor】实现成【多Reactor】，这样就产生了【多 Reactor 多进程 / 线程】方案

多 Reactor 多进程 / 线程方案的示意图如下（以线程为例）：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
方案详细说明如下：

*  主线程中的MainReactor对象通过select监控连接建立事件，收到事件后通过accept对象中的accept获取连接，将新的连接分配给某个子线程
 *  子线程中的SubReactor 对象将MainReactor对象分配的连接加入select继续进行监听，并创建一个Handler用于处理连接的响应事件
 *  如果有新的事件发生时，SubReactor 对象会调用当前连接对应的 Handler 对象来进行响应。
 *  Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程。

多 Reactor 多线程的方案虽然看起来复杂的，但是实际实现时比单 Reactor 多线程的方案要简单的多，原因如下：

*  主线程和子线程分工明确，主线程只负责接收新连接，子线程负责完成后续的业务处理。
 *  主线程和子线程的交互很简单，主线程只需要把新连接传给子线程，子线程无须返回数据，直接就可以在子线程将处理结果发送给客户端。

大名鼎鼎的两个开源软件 Netty 和 Memcache 都采用了「多 Reactor 多线程」的方案。

采用了「多 Reactor 多进程」方案的开源软件是 Nginx，不过方案与标准的多 Reactor 多进程有些差异。

具体差异表现在主进程中仅仅用来初始化 socket，并没有创建 mainReactor 来 accept 连接，而是由子进程的 Reactor 来 accept 连接，通过锁来控制一次只有一个子进程进行 accept（防止出现惊群现象），子进程 accept 新连接后就放到自己的 Reactor 进行处理，不会再分配给其他子进程。

# Proactor #

前面提到的 Reactor 是非阻塞同步网络模式，而 Proactor 是**异步网络模式**。

这里先给大家复习下阻塞、非阻塞、同步、异步 I/O 的概念。

先来看看阻塞 I/O，当用户程序执行 read ，线程会被阻塞，一直等到内核数据准备好，并把数据从内核缓冲区拷贝到应用程序的缓冲区中，当拷贝过程完成，read 才会返回。

注意，阻塞等待的是「内核数据准备好」和「数据从内核态拷贝到用户态」这两个过程。过程如下图：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 3]  
知道了阻塞 I/O ，来看看非阻塞 I/O，非阻塞的 read 请求在数据未准备好的情况下立即返回，可以继续往下执行，此时应用程序不断轮询内核，直到数据准备好，内核将数据拷贝到应用程序缓冲区，read 调用才可以获取到结果。过程如下图：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/837d0f6838ab4caaaf056d359aa0ab96.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/e3a9785cd951496490453fd69878c180.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/6e06b888a83744fd854cca8064381670.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/de6266f61e8d4b2596523ce7c4d4c6ac.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/697244f1366845099d5ee6cc36a21131.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/f18965833c314cc98062b669d771d505.png