部分内容来源：小林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和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 方案
Proactor快速复习
Reactor 依赖 【就绪通知】，Proactor 依赖 【完成通知】
Reactor是内核会给应用发一个【可读事件】应用收到这个事件后，必须主动调用 read()
Proactor是当这一切都做完后，内核给应用发一个【读完成事件】
Proactor 监听到的是 【I/O 已经做完了】，应用不需要自己动手做 I/O
Reactor和Proactor的区别
Reactor：
事件触发后，需要应用进程主动调用 read()/write() 完成数据的搬运
Proactor：
事件触发后，自动调用read（）/write（）读写数据，无需主动发起
Proactor是基于select/poll这些IO多路复用机制
而Proactor是基于异步IO接口实现的
执行流程：
初始化器创建Proactor和Handler，通过异步操作处理器完成注册
异步操作处理器处理send（）/wirte（）完成IO，完成后通知Reacrtor读写操作结束
Proactor收到通知后，调用Handler,Handler处理I/O结果