Nginx中异步事件驱动架构如何调度网络事件

Nginx采用单worker进程+非阻塞I/O+epoll事件通知的异步架构：epoll_wait按最近超时设阻塞时间，就绪即处理；socket全程非阻塞，收发分段续做；事件循环仅调度模块回调，定时器统一由红黑树管理。

Nginx 的异步事件驱动架构调度网络事件，核心在于“单 worker 进程 + 非阻塞 I/O + 操作系统级事件通知机制”三层协同，不靠线程抢占，也不靠轮询等待，而是让内核主动告知“谁有事要办”。

epoll_wait 驱动主循环，只在真正空闲时才阻塞

每个 worker 进程启动后，会初始化一个 epoll 实例，并把监听套接字（如 80 端口）的 EPOLLIN 事件注册进去。之后进入主循环，反复调用 epoll_wait()：

• 它不是一直等，而是设一个超时时间——取自当前所有连接中最近的超时点（比如某个 keepalive 连接还剩 29 秒）
• 若期间有 socket 就绪（新连接到达、客户端发来数据、后端响应可读、发送缓冲区腾出空间），epoll_wait 立即返回就绪列表
• 若无就绪事件，且也无定时器到期，才会短暂阻塞；一旦有事发生，立刻唤醒处理

连接全程 non-blocking，收发分段续做

每个 socket 都被设为非阻塞模式，事件处理不追求“一次读完”或“一次发完”，而是按需分段推进：

• accept 新连接时，尽可能 accept 所有已排队连接，避免遗漏
• recv() 读请求头：若只收到部分，返回 EAGAIN，不等，先去处理其他就绪连接
• send() 发响应：若内核缓冲区满，只发能发的部分，剩余数据留在 connection 的 output buffer 中，并注册 EPOLLOUT 事件，等下次可写再继续
• 这样同一个 worker 可交错处理 A 连接读头、B 连接等 upstream、C 连接发文件，互不阻塞

事件分发由模块回调完成，逻辑与调度解耦

事件循环本身不解析 HTTP 或转发请求，它只负责“叫谁干活”：

• 当某个 socket 触发 EPOLLIN，事件循环调用该连接绑定的 read handler（通常是 ngx_http_wait_request_handler）
• handler 内部触发 HTTP 模块的阶段回调（如 rewrite → access → content），每个阶段由对应模块实现
• upstream 模块在建立后端连接、接收响应时，同样注册自己的读写事件回调，不阻塞主流程
• 所有模块都必须快速返回，不能同步等待磁盘读、DNS 查询或长循环计算

定时器和超时也纳入事件体系，统一管理

连接空闲超时、读写超时、keepalive 超时等，不是靠独立线程轮询，而是：

• 全部插入红黑树，按到期时间排序
• 每次 epoll_wait 返回前，检查红黑树顶端是否到期；若到期，触发对应超时回调（如关闭空闲连接）
• 这样既保证精度，又避免额外线程开销