3. 事件驱动核心概念

事件驱动网络服务的本质，是把“等待 I/O 就绪”这件事从线程阻塞中解放出来，交给一个统一的事件循环去管理。要真正理解它，需要先厘清五个核心概念：事件、事件循环、事件分发器、回调，以及由它们组合出的两种经典模式——反应器（Reactor）与主动器（Proactor）。

事件：被描述的就绪状态

在网络编程语境中，事件并不是“数据到达”本身，而是内核告诉应用程序“某个文件描述符已经处于可读/可写/异常状态”的通知。常见事件类型包括：可读事件（EPOLLIN）、可写事件（EPOLLOUT）、对端关闭（EPOLLRDHUP）、错误（EPOLLERR）以及边缘触发下的挂起状态（EPOLLET）。事件通常以结构体形式携带 fd、事件掩码和用户数据指针，例如 Linux epoll 的 struct epoll_event。理解事件的关键在于：它是“状态通知”，不是“数据搬运”，真正的读写仍由应用层完成。

事件循环：驱动一切的心脏

事件循环是一个持续运行的循环体，典型结构如下：

while (running) {
    n = epoll_wait(epfd, events, MAX_EVENTS, timeout);
    for (i = 0; i < n; i++) {
        dispatch(events[i]);   // 交给分发器处理
    }
    run_pending_tasks();       // 处理定时器/延迟任务
}

它负责三件事：等待事件、把事件交给分发器、在空闲时执行定时任务或延迟回调。事件循环本身不关心业务逻辑，它只保证“有事件就处理、没事件就等待”，从而避免忙轮询浪费 CPU。

事件分发器：从事件到处理者的路由

事件分发器维护一张“fd → 处理器”的映射表。当 epoll_wait 返回一批事件后，分发器根据每个事件中的 fd 找到对应的处理器对象，并调用其 handle_event() 方法。分发器通常还负责注册、修改、删除 fd 的监听关系。它的核心价值是解耦：事件循环不需要知道具体业务，业务也不需要关心底层 I/O 多路复用细节。

回调：事件驱动的执行单元

回调是事件发生时被调用的函数或方法。在 C++ 中可以是 std::function，在 C 中可以是函数指针加 void* 上下文。回调的设计要点是：尽量短小、非阻塞，避免在回调中执行耗时计算或同步 I/O。如果必须做重活，应把任务投递到线程池或延迟队列，让事件循环尽快回到等待状态。

反应器模式：同步等待，就绪后回调

反应器模式的核心是“同步 I/O + 事件通知”。应用注册感兴趣的事件，事件循环等待就绪，分发器调用回调，回调中执行非阻塞的 read/write。整个过程中，数据搬运由应用自己完成。Reactor 的优点是实现简单、可控性强，适合连接数多但单连接数据量不大的场景，如即时通讯、代理服务器。

主动器模式：异步提交，完成时回调

主动器模式的核心是“异步 I/O + 完成通知”。应用发起异步读/写（如 io_uring、Windows IOCP、POSIX AIO），内核在后台完成数据搬运，完成后通知应用，回调中直接拿到结果。Proactor 的优点是应用层无需关心“就绪后还要自己读”，吞吐更高，但实现复杂，且依赖操作系统对异步 I/O 的支持程度。

两种模式的选型判断

选择 Reactor 还是 Proactor，主要看三点：操作系统支持、业务数据量、以及团队对复杂度的容忍度。Linux 上 epoll 天然适合 Reactor；Windows 上 IOCP 是 Proactor 的典型实现；Linux 的 io_uring 则让 Proactor 在 Linux 上变得实用。如果单连接数据量大、拷贝开销显著，Proactor 更有优势；如果连接数极多但每次数据很小，Reactor 的简单直接往往更划算。

一个最小可观察的示例

假设用 epoll 监听两个 fd：监听套接字 listen_fd 和已连接套接字 conn_fd。注册时分别绑定 accept_handler 和 echo_handler。当新连接到达，epoll_wait 返回 listen_fd 可读，分发器调用 accept_handler，后者 accept 出新 fd 并注册 EPOLLIN。当客户端发来数据，conn_fd 可读，分发器调用 echo_handler，后者 read 后立即 write 回显。整个过程没有线程阻塞，一个线程即可服务成百上千连接。

理解这五个概念之后，事件驱动框架的代码结构就不再神秘：事件循环是骨架，分发器是神经中枢，回调是肌肉，事件是信号，而 Reactor 与 Proactor 则是两种不同的信号处理哲学。掌握它们，才能在实际开发中做出合理的架构选择，并在性能调优时准确判断瓶颈所在。