在软件设计中，尤其是服务器端或网络编程领域，用于处理并发和 I/O 的模型并不只有“事件驱动、非阻塞式 I/O”（Node.js 的模式）。以下是常见的几种并发模型或 I/O 模型，了解它们可以帮助我们更好地理解不同系统或语言的并发与 I/O 处理方式。
1. 多线程阻塞式 I/O
特点：
-
每个请求由一个线程来处理，线程内部采用阻塞式 I/O。
-
当线程在等待 I/O 时（例如等待磁盘或网络读取）会被阻塞，无法继续执行。
-
为了提升并发，通常会创建大量线程来处理更多请求。
优点：
• 编程模型简单，逻辑清晰，和同步思维方式最接近。
缺点：
• 当并发量过高时，会消耗大量系统资源（线程上下文切换开销、内存开销），易出现“线程爆炸”。
• 大量阻塞操作会拖慢系统整体响应。
很多传统的服务器端语言和框架，早期都采用这种模型，如 Java 的早期 Thread per request 模式、C/C++ 服务器、PHP 的 Apache MPM- prefork 等。
2. 多线程 + 非阻塞（异步）I/O
特点：
-
多线程和异步 I/O 相结合，每个线程可同时管理多个 I/O 操作。
-
当某个 I/O 操作发起后，如果需要等待，则交由操作系统或线程池去处理，线程不会被长时间阻塞。
-
适合对线程数量有限制，又想利用异步 I/O 提升并发处理能力的场景。
优点：
• 可以较好地利用多核 CPU，多个线程并行执行，提升吞吐量。
• 异步 I/O 避免了线程长时间阻塞，减少了上下文切换。
缺点：
• 编程复杂度较高，需要同时处理线程安全问题和异步回调问题。
• 调试和排查问题可能比较困难。
例如，Java 的 NIO（New I/O）或 Netty 框架，都可以被看作是在多线程环境下实现的异步非阻塞 I/O。
3. Reactor 模型 / Proactor 模型
特点：
- 这两种模型都属于 事件驱动 和 回调 机制。
2. Reactor 模型 下，主线程（或主循环）只负责分发 I/O 事件，具体的 I/O 读写在业务线程（或回调）中进行；
3. Proactor 模型 下，I/O 操作在操作系统层面完成后，通知应用层执行业务逻辑；
- Node.js 底层基于 libuv，可以看作是一种 Reactor + 线程池 的混合实现。
优点：
• 事件驱动，单线程也能处理高并发 I/O（适合网络编程场景）。
• 在大多数操作系统上可以高效工作（epoll、kqueue、IOCP 等）。
缺点：
• 对于 CPU 密集型任务，需要额外的线程或进程处理。
• 编程模型需要使用回调或 Promise 等，代码结构相对复杂。
4. Actor 模型
特点：
-
一切实体（Actor）都被看作是独立的“微进程”，它们之间通过发送消息来通信。
-
每个 Actor 拥有自己的状态，消息驱动行为，不共享内存。
-
常见于 Erlang/OTP、Akka（Scala/Java 生态）等。
优点：
• 高度解耦，不同 Actor 之间可以分布式部署，并行扩展。
• 并发安全性好，因为不共享内存、只能通过消息通信。
缺点：
• 开发者需要转变思维方式去理解消息驱动。
• 对于简单场景可能显得过于复杂。
5. 协程 / 纤程（Coroutine / Fiber）模型
特点：
-
在单一（或有限的）线程中，通过用户态调度来实现并发。
-
每个协程看似是顺序同步的，但在底层会在 I/O 等待时切换到其他协程继续执行，达到并发效果。
-
Go 的 goroutine、Python 的 gevent、Lua 的协程都是代表。
优点：
• 编程模式比回调更直观（像写同步代码）。
• 用户态切换开销比系统线程轻量。
缺点：
• 需要语言或运行时支持，否则需要第三方库进行封装。
• 如果协程中出现阻塞操作（或长时间计算），仍会阻塞所在线程。
6. 多进程模型
特点：
-
每个请求或每组请求由一个独立的进程来处理。
-
进程之间通过 IPC（进程间通信）或网络通信进行协作。
-
在操作系统层面隔离更彻底，可靠性更高（单个进程崩溃不会影响其他进程）。
优点：
• 隔离性好，可多机部署或分布式扩展。
• 可以充分利用多核。
缺点：
• 进程间通信成本比线程高。
• 资源占用比单一进程/线程更大。
很多面向微服务架构的系统，会将各个服务拆分为不同的进程甚至容器（Docker）运行，从而进行水平扩展。
7. 总结
• Node.js 是典型的 单线程 + 事件驱动 + 非阻塞式 I/O 模式，通过底层的 libuv 线程池把阻塞 I/O 变成异步回调，对外表现为事件循环单线程。
• 此外，还有 多线程阻塞式 I/O、多线程 + 异步 I/O、Reactor/Proactor、Actor、协程、多进程 等各种模型和组合，不同场景下有不同的平衡与取舍。
• 在选择并发模型时，需要考虑 开发难度、硬件环境、系统可靠性、吞吐量、响应时间 等因素，选择最符合业务需求的方案。
