C++ IO框架 - Reactor 和 Proactor

• C++ IO框架 - Reactor 和 Proactor
  • 参考资料
  • 概述
  • Reactor 模式
  • 单 Reactor 单进程
  • 单 Reactor 多线程 / 多进程
  • 多 Reactor 多进程 / 线程
  • Proactor

参考资料

• Reactor 和 Proactor 为什么性能高？ (opens new window)

概述

概念：

• PPC,Process per Connection，每次有新的连接就新建一个进程去专门处理这个连接的请求。
• TPC,Thread per Connection，每次有新的连接就新建一个线程去专门处理这个连接的请求，比PPC更轻量。

服务器连接多个客户端的业务场景:

• 要让服务器服务多个客户端————>最直接的方式是为每一条连接创建线程。

  • 其实创建进程也是可以的，原理是一样的。进程和线程的区别在于线程比较轻量级些，线程的创建和线程间切换的成本要小些，为了描述简述，后面都以线程为例。
  • 处理完业务逻辑后，随着连接关闭后线程也同样要销毁了，但是这样不停地创建和销毁线程，不仅会带来性能开销，也会造成浪费资源，而且如果要连接几万条连接，创建几万个线程去应对也是不现实的。

• 要这么解决这个问题呢？可以采用资源复用的方式。

  • 即不再为每个连接创建线程，而是创建一个线程池，将连接分配给线程，然后一个线程可以处理多个连接的业务。
  • 思考？ 线程怎样才能高效地处理多个连接的业务？
  • 当一个连接对应一个线程时，线程一般采用「read -> 业务处理 -> send」的处理流程，如果当前连接没有数据可读，那么线程会阻塞在 read 操作上（ socket 默认情况是阻塞 I/O），不过这种阻塞方式并不影响其他线程。
  • 但是引入了线程池，那么一个线程要处理多个连接的业务，线程在处理某个连接的 read 操作时，如果遇到没有数据可读，就会发生阻塞，那么线程就没办法继续处理其他连接的业务。
  • 要解决上述问题，最简单的方式就是将 socket 改成非阻塞，然后线程不断地轮询调用 read 操作来判断是否有数据，这种方式虽然该能够解决阻塞的问题，但是解决的方式比较粗暴，因为轮询是要消耗 CPU 的，而且随着一个 线程处理的连接越多，轮询的效率就会越低。

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

  • 思考？有没有办法在只有当连接上有数据的时候，线程才去发起读请求呢？答案是有的，实现这一技术的就是 I/O 多路复用。
  • I/O 多路复用技术会用一个系统调用函数来监听所有关心的连接，即在一个线程里可监控很多的连接。
  • 我们熟悉的 select/poll/epoll 就是内核提供给用户态的多路复用系统调用，线程可以通过一个系统调用函数从内核中获取多个事件。

select/poll/epoll 是如何获取网络事件的呢？

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

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

I/O多路复用结合线程池的思想，成就了 Reactor。

Reactor 模式

Reactor 模式(也称Dispatcher模式)主要由 Reactor 和 处理资源池 这两个核心部分组成，作用如下:

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

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

Reactor 的数量可以只有一个，也可以有多个； 处理资源池可以是单个进程 / 线程，也可以是多个进程 /线程； 将上面的两个因素排列组设一下，理论上就可以有 4 种方案选择:

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

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

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

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

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

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

单 Reactor 单进程

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

• Reactor 监听和分发事件；
• Acceptor 获取连接；
• Handler 处理业务；

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

接下来，介绍下「单 Reactor 单进程」这个方案:

• Reactor对象通过select(或poll、epoll)监听事件，收到事件后通过 dispatch 进行分发。具体分发给 Acceptor 对象还是 Handler 对象，是依据收到的事件类型；
• 如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
• 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；
• Handler 对象通过 read -> 业务处理 -> send 的流程来完成完整的业务流程。

单Reactor单进程方案的优缺点:

• 优点:

  • 全部工作都在同一个进程内完成，实现比较简单，不需要考虑进程间通信和多进程竞争。

• 缺点:

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

• 应用场景:

  • 不适用计算机密集型的场景，只适用于业务处理非常快速的场景。

单 Reactor 多线程 / 多进程

详细说一下这个方案:

• Reactor对象通过select(或poll、epoll)监听事件，收到事件后通过 dispatch 进行分发。具体分发给 Acceptor 对象还是 Handler 对象，是依据收到的事件类型；
• 如果是连接建立的事件，则交由 Acceptor 对象进行处理，Acceptor 对象会通过 accept 方法 获取连接，并创建一个 Handler 对象来处理后续的响应事件；
• 如果不是连接建立事件， 则交由当前连接对应的 Handler 对象来进行响应；

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

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

单Reactor多线程方案的优缺点:

• 优点:
  • 能够充分利用多核 CPU 的能;
• 缺点:
  • 引入多线程，带来了多线程竞争资源的问题。
  • 例如，子线程完成业务处理后，要把结果传递给主线程的 Reactor 进行发送，这里涉及共享数据的竞争。
  • 要避免多线程由于竞争共享资源而导致数据错乱的问题，就需要在操作共享资源前加上互斥锁，以保证任意时间里只有一个线程在操作共享资源，待该线程操作完释放互斥锁后，其他线程才有机会操作共享数据。

相比于单Reactor多线程的方案，单 Reactor 多进程的方案实现起来很麻烦:

• 要考虑子进程 <-> 父进程的双向通信，并且父进程还得知道子进程要将数据发送给哪个客户端。
• 多线程间可以共享数据，虽然要额外考虑并发问题，但是这远比进程间通信的复杂度低得多，因此实际应用中也看不到单 Reactor 多进程的模式。

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

多 Reactor 多进程 / 线程

方案详细说明如下:

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

Proactor

Reactor 是非阻塞同步网络模型，因为真正的 read和 send操作都需要用户进程同步操作。这里的“同步”指用户进程在执行read和send这类I/O 操作的时候是同步的，如果把I/O操作改为异步就能够进一步提升性能，这就是异步网络模型 Proactor。

• Reactor 理解成 “事件反应”，即来了事件我通知你，你来处理
• Proactor 理解成 “主动器”，即来了事件我来处理，处理完了我通知你。
• 这里的“我”就是操作系统内核，“事件”就是有新连接、有数据可读、有数据可写这些I/O事件。

Proactor 模型示意图如下：

方案详细说明如下:

1. Proactor Initiator 负责创建Proactor和 Handler，并将Proactor和Handler 都通过Asynchronous Operation Processor 注册到内核。
2. Asynchronous Operation Processor 负责处理注册请求，并完成I/O操作。
3. Asynchronous Operation Processor 完成 I/O 操作后通知 Proactor。
4. Proactor 根据不同的事件类型可调不同的Handler 进行业务处理。
5. Handler 完成业务处理，Handler 也可以注册新的 Handler 到内核进程。

详细的处理过程如下：

理论上 Proactor 比 Reactor 效率要高一些，异步I/O 能够充分利用 DMA特性，让I/O操作与计算重叠。

但实现真正的异步I/O，操作系统需要做大量的工作，目前 Windows下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下的 AIO 并不完善，因此在 Linux下实现高并发网络编程时都是以 Reactor 模式为主。所以即使 boost asio 号称实现了 proactor 模型，其实它在Windows下采用IOCP，而在Linux下是用Reactor模式(采用enoll)模拟出来的异步模型。