🔍搜索 K

0 字

阅读约 1 分钟

几种网络模型

一连接一线程 (Thread-Per-Connection)

说明
核心思想：为每一个新的客户端连接都分配一个独立的线程来处理该连接上的所有请求。
一般结合线程池使用，以复用线程，减少线程创建和销毁的开销。如
典型的例子是传统的阻塞式 Socket 服务端编程，以及早期版本的 Tomcat (BIO Connector)、Spring MVC (在其传统的 Servlet 容器部署模型下，每个请求通常由一个容器线程处理)。
优点
编程模型简单：逻辑直观，易于理解和实现
请求隔离性好：一个连接的处理如果出现阻塞或异常，通常不会直接影响到其他连接（除非是共享资源问题）。
对于 I/O 密集型且连接数不是非常巨大的场景，如果线程能够快速完成 I/O 操作并释放，或者 CPU 资源充足，系统仍能表现出一定的处理能力。
不足
线程资源消耗大：每个线程都需要分配独立的栈空间（通常1MB左右），当连接数增多时，内存消耗显著。
CPU 切换开销大：大量线程会导致频繁的上下文切换，尤其是在线程数远超 CPU核心数时，CPU 时间会大量浪费在线程调度上，而非实际业务处理。
系统线程数限制：操作系统对可创建的线程数有上限（受内存、PID 数量等限制），导致并发连接数受限，可伸缩性差。
不适合高并发长连接场景：如果大量连接长时间保持但并不活跃，会造成大量线程空闲等待，浪费系统资源。

Reactor (反应器) 模式

说明
核心思想：基于同步 I/O 事件驱动。它依赖一个或多个输入源，服务器程序注册对特定类型 I/O 事件的兴趣（如新连接建立、数据可读、数据可写）。当这些事件发生时，Reactor 组件负责检测事件，并将事件分发给预先注册的相应处理器（Handler）去进行实际的 I/O 操作和业务处理。
关键组件：
Reactor (反应器)：负责监听和分派事件。它等待 I/O 事件的发生，一旦发生，就通知相应的 Handler。
Event Handler (事件处理器)：负责处理特定类型的事件。通常包含对 I/O 句柄的操作（如读取数据、发送数据）和业务逻辑。
Event Demultiplexer (事件多路分用器)：这是 Reactor 的核心，由操作系统提供（如 select, poll, epoll on Linux, kqueue on BSD/macOS）。它能同时监视多个 I/O 句柄，并在任何一个句柄准备好 I/O 操作时通知 Reactor。
工作流程：
应用程序将事件处理器（Handler）注册到 Reactor，并指定其关注的事件类型（如 READ_EVENT, WRITE_EVENT, ACCEPT_EVENT）和对应的 I/O 句柄（如 Socket）。
Reactor 调用事件多路分用器（如 epoll_wait）阻塞等待事件。
当某个或某些句柄上发生所关注的事件时，事件多路分用器返回，通知 Reactor。
Reactor 根据发生的事件类型，将事件分发给对应的已注册的 Handler。
Handler 执行非阻塞的 I/O 操作（如 read(), write()），然后执行相关的业务逻辑。如果业务逻辑耗时较长，通常会将其提交到后端的线程池处理，以避免阻塞 Reactor 线程。
典型实现：Netty (Java), Node.js (JavaScript), Twisted (Python), Redis (C), Nginx (C)。通常结合 epoll (Linux) + Thread Pool (用于处理耗时业务逻辑)。
只需要一个或少量线程（Reactor 线程）就可以处理大量的并发连接。
优点
高并发处理能力：通过事件驱动和非阻塞 I/O，少量线程即可管理大量连接，资源利用率高。
可伸缩性好：可以通过增加 Reactor 线程或 Handler 线程池的大小来扩展处理能力。
响应性高：Reactor 线程专注于事件分发，避免了因单个请求阻塞而影响其他请求的情况。
不足
编程模型相对复杂：相比一连接一线程模型，事件驱动和回调机制使得代码逻辑更分散，调试难度增加。
Handler 中不能有长时间阻塞操作：如果 Handler 中的 I/O 操作或业务逻辑是阻塞的，且直接在 Reactor 线程中执行，会导致整个 Reactor 阻塞，无法响应其他事件。因此耗时操作通常需要异步化或交给独立的线程池处理。
处理请求的延迟可能略高：因为请求需要先经过 Reactor 分发，再到 Handler 处理，相比直接由线程处理可能多一层间接性。但在高并发下，其整体吞吐量远超传统模型。

Proactor (主动器) 模式

说明
核心思想：基于异步 I/O 事件驱动。与 Reactor 不同，Proactor 模式中，当应用程序发起一个异步 I/O 操作（如异步读、异步写）时，它会将操作本身、数据缓冲区、以及操作完成后的回调处理器 (Completion Handler) 注册给操作系统或异步 I/O 框架。操作系统或框架会主动完成整个 I/O 操作（例如，读取数据到指定的缓冲区），并在操作完成后通知应用程序，调用预设的 Completion Handler。
关键组件：
Proactor (主动器)：作为异步事件解复用器，负责接收操作系统完成 I/O 操作的通知，并将完成事件分发给相应的 Completion Handler。
Completion Handler (完成处理器)：包含在 I/O 操作完成时需要执行的逻辑。它不执行 I/O 操作本身，而是处理已完成的 I/O 操作的结果。
Asynchronous Operation Processor (异步操作处理器)：由操作系统内核或底层库实现，负责执行实际的异步 I/O 操作，并在完成后通知 Proactor。
Initiator (发起者)：应用程序代码，负责创建 Completion Handler、数据缓冲区，并发起异步 I/O 操作。
工作流程：
应用程序调用一个异步 I/O 操作函数（如异步 read 或 write），并提供一个缓冲区、操作所需信息以及一个 Completion Handler。
操作系统或异步 I/O 框架接管该 I/O 操作，应用程序可以立即返回并继续执行其他任务，不会被阻塞。
操作系统内核在后台完成 I/O 操作（例如，将数据从网络读入应用程序提供的缓冲区）。
I/O 操作完成后，操作系统通知 Proactor。
Proactor 将完成事件（包含结果、状态等）和对应的 Completion Handler 放入完成队列或直接调度 Completion Handler。
Completion Handler 被调用，处理 I/O 操作的结果（如使用已填充的数据，检查写入是否成功等）。
典型实现：Windows 的 IOCP (I/O Completion Ports)，POSIX AIO (虽然 POSIX AIO 的某些实现可能不完全是“真”异步或性能不佳)，Boost.Asio (C++) 库可以工作在 Proactor 模式，Java NIO.2 (AsynchronousSocketChannel 等)。
与 Reactor 的核心区别：
Reactor：应用程序注册对“I/O 就绪”事件的兴趣。当事件发生时，Reactor 通知 Handler，Handler 负责执行实际的 I/O 操作（如 read(), write()）。这是“我告诉你什么时候可以读/写了，你自己去读/写”。
Proactor：应用程序发起异步 I/O 操作并提供回调。操作系统/框架负责执行实际的 I/O 操作。当操作完成后，Proactor 通知 Completion Handler 处理结果。这是“你告诉我你要读/写什么以及写到哪里，我读/写完了通知你结果”。
优点
更高的并发性和吞吐量：线程完全从 I/O 操作中解放出来，只在 I/O 操作完成后才被唤醒执行回调，CPU 利用率通常更高。
简化的应用层逻辑：应用层 Handler 不需要关心具体的 I/O 读写过程，只需处理完成后的数据或状态。
更好的性能：尤其是在支持高效内核级异步 I/O 的操作系统上（如 Windows IOCP），可以减少用户态和内核态之间的切换。
不足
编程模型最为复杂：异步回调链使得代码逻辑更难跟踪和调试，状态管理也更复杂。
依赖操作系统支持：真正的 Proactor 模式高度依赖操作系统提供高效的异步 I/O 支持。在缺乏这种支持的平台上，可能需要通过模拟（如使用线程池模拟异步）来实现，效果会打折扣。
内存管理：由于 I/O 操作是异步的，需要确保在操作完成前，传递给操作系统的缓冲区（Buffer）是有效的，并且在操作完成后正确处理，这增加了内存管理的复杂性。