Nginx 的高性能依赖事件队列机制而非单纯非阻塞 I/O：它通过 epoll/kqueue 统一监听 socket 状态变化，批量获取就绪事件并分发处理，配合 O_NONBLOCK 实现零空转、低延迟、高并发连接管理。
非阻塞 I/O 本身不调度，真正实现高性能响应调度的是 Nginx 的事件队列机制——它把“等数据”变成“等通知”，让单个 worker 进程能同时盯住数万连接，只在真正有事时才出手。
事件队列是调度中枢，不是被动等待池
Nginx 并不靠轮询或线程抢占来发现就绪连接，而是把所有 socket（监听套接字 + 已建立连接）统一注册进操作系统级事件通知器（Linux 用 epoll，macOS/BSD 用 kqueue）。这个事件通知器就像一个智能门房：
- 它持续监听成千上万个 fd 的状态变化：可读、可写、出错、超时、断开
- 当某个客户端发来数据，内核立刻标记对应 socket 为“EPOLLIN 就绪”，并放入事件队列
- Nginx 的事件循环（event loop）每次调用 epoll_wait()，就能一次性批量取出多个就绪事件（比如一次拿到 37 个待处理请求）
- 取出后按顺序逐个 dispatch，调用对应的 handler（如 ngx_http_process_request）处理，全程不阻塞
非阻塞 IO 与事件队列必须配合才能闭环
O_NONBLOCK 是前提，但光设了它还不够。若没有事件队列驱动，非阻塞调用只会陷入“反复试探+空转”的低效状态。Nginx 的设计让两者形成闭环：
- recv() 返回 EAGAIN → 连接不释放，继续留在 epoll 监听列表中，等待下次 EPOLLIN 通知
- send() 返回 EAGAIN → 立即注册 EPOLLOUT 事件，等内核缓冲区腾出空间再续发，不重试不忙等
- 后端响应未返回 → 当前请求挂起，worker 马上切走处理其他就绪事件；响应一到，上游模块触发 write 事件唤醒该连接
- 连接断开或超时 → 内核通知 EPOLLHUP 或 EPOLLERR，事件队列立刻投递，Nginx 清理资源，不依赖定时器轮询
关键配置决定事件队列的实际吞吐效率
默认配置跑得动，但高并发下必须调优，否则事件队列会成为瓶颈：
- use epoll;（Linux 必开）：替代低效的 select/poll，时间复杂度接近 O(1)，支持百万级 fd
- multi_accept on;：单次 epoll_wait 可批量接受多个新连接，减少系统调用次数，提升突发流量吞吐
- worker_connections 65536;：单 worker 最大监听连接数，需同步调高系统 ulimit -n，否则新连接被拒
- accept_mutex on;（默认）：避免多 worker 同时争抢 accept，降低锁竞争，让事件分发更均衡
高频连接下的事件生命周期管理
面对每秒数千次建连/断连，事件队列不只是转发，还参与连接状态的精细管控：
- TCP 握手完成 → 触发 accept 事件，分配 connection 结构体，注册 EPOLLIN
- 慢速客户端发请求头 → 每次 read() 得 EAGAIN，连接保持监听状态，不占用 CPU，也不释放 fd
- 响应发送中遇阻塞 → 自动切换监听类型为 EPOLLOUT，事件队列下次唤醒时续发
- 超时或异常 → 由 timer wheel 触发，生成 timeout 事件送入队列，统一由 event loop 清理，避免泄漏
