当前位置：首页 > news >正文

高性能网络模式-Reactor和Preactor

news 2025/7/14 6:56:52

部分内容来源：小林Coding

Reactor-基于同步IO的非阻塞同步模式

进程的三个对象和执行流程

三个对象

① Reactor（反应器）

作用：监听所有连接的 I/O 事件，并将事件分发给对应的 Handler 处理

对应操作：执行 select() 或 epoll() 等系统调用，检测事件就绪

② Acceptor（接受器）

作用：专门处理客户端的连接请求（accept()），创建新连接后将其注册到 Reactor

生命周期：通常只在服务器启动时创建一个 Acceptor 实例

③ Handler（处理器）

作用：处理具体的 I/O 操作（如读取数据、业务逻辑处理、写回响应）

对应操作：执行 read（）、业务处理、write（）

执行流程

接收器-Acceptor 处理客户端连接注册到反应器

反应器-Reactor 监听IO事件将事件交给处理器处理

处理器-Handler 处理具体的IO事件

Handler对象的处理流程：【read -> 业务处理 -> send】

具体调用函数

Reactor做select（查找事件）和dispact（分发事件）

Acceptor做accept（获取连接）

Handler做read（读取数据）和send（发送数据）

单Reactor单线程

PS：C语言和Java语言不过是叫法不同，这两种模型都是单Reactor单进程，并且只有一个主线程来执行。所以单Reactor单进程和单Reactor单线程在这个模型中只是叫法的区别

一般来说，C 语言实现的是「单 Reactor 单进程」的方案

因为 C 语言编写完的程序运行后就是一个独立的进程，不需要在进程中再创建线程

而 Java 语言实现的是「单 Reactor 单线程」的方案

因为 Java 程序是跑在 Java 虚拟机这个进程上面的，虚拟机中有很多线程，我们写的 Java 程序只是其中的一个线程而已

即：JVM是进程，Java程序是JVM其中的一个线程。可以分成用户线程和系统线程

用户线程就是用户写的代码，是用户代码显式创建的
系统线程是 JVM 在启动时自动创建的，用于支撑 Java 运行时环境

系统由 JVM 直接管理，一般情况下用户代码无法直接访问它们

系统线程包括垃圾回收线程、JIT 编译线程、引用处理线程等，它们都运行在 Java 虚拟机进程中

Reactor的作用：监听所有连接的 I/O 事件，并将事件分发给对应的 Handler 处理

进程的三个对象

可以看到进程里有 Reactor、Acceptor、Handler 这三个对象：

Reactor（反应器）对象的作用是监听和分发事件；
Acceptor（接收器）对象的作用是获取连接；
Handler（处理器）对象的作用是处理业务；

三个对象的执行流程

① Reactor（反应器）

作用：监听所有连接的 I/O 事件，并将事件分发给对应的 Handler 处理

对应操作：执行 select() 或 epoll() 等系统调用，检测事件就绪

② Acceptor（接受器）

作用：专门处理客户端的连接请求（accept()），创建新连接后将其注册到 Reactor

生命周期：通常只在服务器启动时创建一个 Acceptor 实例

③ Handler（处理器）

作用：处理具体的 I/O 操作（如读取数据、业务逻辑处理、写回响应）

对应操作：执行 read（）、业务处理、write（）

执行流程：

接收器-Acceptor 处理客户端连接注册到反应器

反应器-Reactor 监听IO事件将事件交给处理器处理

处理器-Handler 处理具体的IO事件

Reactor做select（查找事件）和dispact（分发事件）

Acceptor做accept（获取连接）

Handler做read（读取数据）和send（发送数据）

对象里的 select、accept、read、send 是系统调用函数

dispatch 和「业务处理」是需要完成的操作

其中 dispatch 是分发事件操作

介绍下「单 Reactor 单进程」这个方案

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

单 Reactor 单进程的方案因为全部工作都在同一个进程内完成，所以实现起来比较简单

不需要考虑进程间通信，也不用担心多进程竞争

缺点

单Reactor单线程方案存在 2 个缺点：

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

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

Redis 是由 C 语言实现的，在 Redis 6.0 版本之前采用的正是「单 Reactor 单线程」的方案

因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上而是在网络IO上

所以 Redis 对于命令的处理是单线程的方案

单Reactor多线程

如果要克服「单 Reactor 单线程 / 进程」方案的缺点就需要引入多线程 / 多进程

这样就产生了单 Reactor 多线程 / 多进程的方案

【单 Reactor 多线程】方案

详细说一下这个方案：

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

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

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

多线程竞争资源问题

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

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

要避免多线程由于竞争共享资源而导致数据错乱的问题，就需要在操作共享资源前加上互斥锁

以保证任意时间里只有一个线程在操作共享资源，待该线程操作完释放互斥锁后，其他线程才有机会操作共享数据

【单 Reactor 多进程】方案（几乎没有）

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

事实上，单 Reactor 多进程相比单 Reactor 多线程实现起来很麻烦

主要因为要考虑子进程 <-> 父进程的双向通信，并且父进程还得知子进程要将数据发送给哪个客户端

而多线程间可以共享数据，虽然要额外考虑并发问题，但是这远比进程间通信的复杂度低得多

因此实际应用中也看不到单 Reactor 多进程的模式

【单 Reactor】模式的问题

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

多Reactor多线程

要解决「单 Reactor」的问题，就是将「单 Reactor」实现成「多 Reactor」

【 Reactor 多进程 / 线程】方案

方案详细说明如下：

主线程中的 MainReactor 对象通过 select 监控连接建立事件，收到事件后通过 Acceptor 对象中的 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 进行处理，不会再分配给其他子进程

Reactor快速复习

三个对象的执行流程

接收器-Acceptor 处理客户端连接注册到反应器

反应器-Reactor 监听IO事件将事件交给处理器处理

处理器-Handler 处理具体的IO事件

Handler对象的处理流程：【read -> 业务处理 -> send】

三模型汇总

单 Reactor 单线程模型：一个线程包含所有组件

单 Reactor 多线程模型：Reactor+Acceptor 在一个线程，Handler 在多线程

主从 Reactor 多线程模型：主 Reactor 线程包含多Acceptor，从 Reactor 线程包含多Handler

单Reactor/单线程

单 Reactor 单线程的方案因为全部工作都在同一个进程内完成，所以实现起来简单

不需要考虑进程间通信，也不用担心多进程竞争

单Reactor单线程方案存在 2 个缺点：

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

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

Redis 是由 C 语言实现的，在 Redis 6.0 版本之前采用的正是「单 Reactor 单线程」的方案

因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上而是在网络IO上

所以 Redis 对于命令的处理是单线程的方案

单Reactor/多线程

大部分和单线程一样

区别如下：

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

Handler主线程负责接收和发送

Hadler子线程负责业务处理

多线程存在的资源竞争问题：

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

要避免多线程由于竞争共享资源而导致数据错乱的问题，就需要在操作共享资源前加上互斥锁

单Reactor存在的问题：

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

多Reactor多线程

主Reactor多Acceptor，监听（select）连接，并将新连接分发（dispatch）给子Reactor，无需阻塞的等待业务执行完

从Reactor多Handler，多线程处理连接

Proactor-基于异步IO的异步网络模式

Reactor和Proactor的区别

Reactor 是非阻塞同步网络模式，感知的是就绪可读写事件
在每次感知到有事件发生（比如可读就绪事件）后，就需要应用进程主动调用 read 方法来完成数据的读取，也就是要应用进程主动将 socket 接收缓存中的数据读到应用进程内存中
这个过程是同步的，读取完数据后应用进程才能处理数据

Proactor 是异步网络模式，感知的是已完成的读写事件
在发起异步读写请求时，需要传入数据缓冲区的地址（用来存放结果数据）等信息，这样系统内核才可以自动帮我们把数据的读写工作完成
这里的读写工作全程由操作系统自动来做，并不需要像 Reactor 那样还需要应用进程主动发起 read/write 来读写数据，操作系统完成读写工作后，就会通知应用进程直接处理数据。

因此，Reactor 可以理解为「来了事件操作系统通知应用进程，让应用进程来处理」

而 Proactor 可以理解为「来了事件操作系统来处理，处理完再通知应用进程」

这里的「事件」就是有新连接、有数据可读、有数据可写的这些 I/O 事件，这里的「处理」包含从驱动读取到内核以及从内核读取到用户空间

举个实际生活中的例子，Reactor 模式就是快递员在楼下，给你打电话告诉你快递到你家小区了，你需要自己下楼来拿快递

在 Proactor 模式下，快递员直接将快递送到你家门口，然后通知你

无论是 Reactor，还是 Proactor都是一种基于「事件分发」的网络编程模式

区别在于 Reactor 模式是基于「待完成」的 I/O 事件

而 Proactor 模式则是基于「已完成」的 I/O 事件

Proactor模式示意图

核心组件

Proactor Initiator：Proactor 初始化器

Handler：处理器 / 处理程序

Asynchronous Operation Processor：异步操作处理器

Proactor（内核和应用间的桥梁）

工作流程

介绍一下 Proactor 模式的工作流程：

初始化与注册：Proactor Initiator（初始化器）创建 Proactor（事件分发器）和 Handler（业务处理器），并通过 Asynchronous Operation Processor（异步操作处理器，内核组件）完成注册，相当于 “提交 I/O 任务 + 绑定结果处理器”。
内核执行 I/O：Asynchronous Operation Processor 接管任务，在内核态完成实际的读写操作（无需应用干预）。
完成通知：I/O 完成后，Asynchronous Operation Processor 主动通知 Proactor “任务做完了”。
事件分发：Proactor 收到通知，根据事件类型调用对应的 Handler（比如读事件调读 Handler，写事件调写 Handler ）。
业务处理：Handler 直接处理 I/O 结果（如解析数据、返回响应），完成业务逻辑

初始化器创建Proactor和Handler，通过异步操作处理器完成注册

异步操作处理器处理send（）/wirte（）完成IO，完成后通知Reacrtor读写操作结束

Proactor收到通知后，调用Handler,Handler处理I/O结果

可惜的是，在 Linux 下的异步 I/O 是不完善的，aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案

而 Windows 里实现了一套完整的支持 socket 的异步编程接口，这套接口就是 IOCP

是由操作系统级别实现的异步 I/O，真正意义上异步 I/O

因此在 Windows 里实现高性能网络程序可以使用效率更高的 Proactor 方案