nginx事件驱动架构靠单worker内事件循环+epoll/kqueue就绪通知+非阻塞socket实现高并发，本质是“等通知、不轮询、非阻塞、按需调度”，通过reactors模式分发、非阻塞处理、状态重注册闭环管理连接。
Nginx 的事件驱动架构不是靠“多开线程”来扛并发，而是靠一个 Worker 进程内持续运转的事件循环，配合操作系统级的高效 I/O 多路复用机制，实现单线程高密度处理成千上万连接。它的 IO 事件响应逻辑本质是“等通知、不轮询、非阻塞、按需调度”，优化空间也正藏在这一整套协同链路中。
IO 事件如何被感知和捕获
NGINX 启动时会根据系统自动选用最合适的底层机制：Linux 用 epoll，FreeBSD/macOS 用 kqueue，老旧或兼容场景才回退到 select。它们的核心作用是一致的——让内核替用户进程盯住一批文件描述符（如监听 socket、客户端连接 socket），一旦有数据可读、可写、出现新连接或异常，就立刻“推”一个事件给 NGINX，而不是让 NGINX 自己反复去问“好了没？”
关键细节：
- epoll 使用红黑树管理注册 FD，O(logN) 插入/删除；就绪事件通过链表直接返回，无需遍历全部 FD
- kqueue 支持更广的事件类型（如文件变更、子进程退出），且 kevent 调用支持批量事件提交与获取
- NGINX 默认启用边缘触发（ET）模式，减少重复通知，但要求应用层必须一次性读完/写完，否则可能漏事件
事件从就绪到执行的调度路径
当 epoll_wait 或 kevent 返回一批就绪事件后，NGINX 并不会立刻调用业务逻辑。它走的是标准 Reactor 模式三步链路：
- 事件分发：遍历就绪事件列表，根据 fd 类型（监听 socket / 已连接 socket）和事件类型（EPOLLIN / EPOLLOUT / EPOLLERR）路由到对应 handler
- 非阻塞处理：对读事件，循环调用 recv() 直到返回 EAGAIN；对写事件，只发当前缓冲区能容纳的数据，未发完则注册 EPOLLOUT 继续等待
- 状态重注册：一次读完请求头后，若需继续读请求体，则保持 EPOLLIN；若要发响应，则改注册 EPOLLOUT；连接关闭则从事件表移除
这个闭环确保每个 socket 始终处于“恰如其分”的监听状态，避免无效等待或事件丢失。
影响响应效率的关键优化点
真正决定 IO 响应快慢的，往往不在 epoll 本身，而在 NGINX 如何与它配合。几个实操中容易忽略但效果显著的点：
- worker_connections 需匹配系统限制：该值不能超过 ulimit -n 设置，否则多余连接会被拒绝；建议设为 soft limit 的 90%
- 启用 accept_mutex 减少惊群：多个 worker 共享监听端口时，开启此开关可避免所有 worker 同时被唤醒争抢新连接
- 调整 sendfile 和 tcp_nopush/tc_nodelay：静态文件传输优先用 sendfile 避免内核-用户空间拷贝；小响应启 tcp_nodelay 减少 Nagle 延迟；大响应启 tcp_nopush 合并 TCP 包
- read_ahead 和 aio 配合磁盘 IO：对大文件或高吞吐静态服务，开启异步 IO（aio on; directio 4k;）可避免 worker 阻塞在磁盘读取上
常见响应延迟的排查线索
如果发现某些请求响应变慢，优先检查是否卡在事件流转的某个环节：
- 日志中出现大量 "*XXX client timed out"：大概率是读超时（client_header_timeout / client_body_timeout）设置过短，或后端处理阻塞导致无法及时读完
- 监控显示 active connections 高但 reading/writing 比例失衡：可能是某类请求（如长轮询、流式响应）未正确管理事件状态，导致 socket 长期挂载在错误事件上
- epoll_wait 调用耗时突增：说明就绪事件量暴增或内核事件队列积压，需结合 netstat 查看 TIME_WAIT 连接数、是否有连接未正常关闭
