nginx事件循环基于操作系统异步i/o机制（如epoll）实现高性能并发处理，每个worker进程独享一个事件循环，通过注册fd、批量分发就绪事件、状态机驱动handler完成请求生命周期管理。
Nginx 的事件循环（Event Loop）是其高性能的核心机制之一，它不依赖多线程或多进程轮询，而是基于操作系统提供的异步 I/O 通知机制（如 epoll、kqueue、IOCP），实现对大量并发连接的高效监听与事件分发。
EventLoop 的底层基础：事件驱动模型
Nginx 在启动时会根据运行平台自动选择最优的事件驱动模块（如 Linux 下默认用 epoll，FreeBSD 用 kqueue）。这些机制允许内核在 socket 状态就绪（如可读、可写、发生错误）时主动通知应用，避免了传统 select/poll 的遍历开销。
每个 worker 进程都拥有独立的 EventLoop，即一个循环 + 一个事件队列 + 一个事件分发器。worker 不阻塞等待连接，而是在循环中持续调用事件接口（如 epoll_wait()），获取就绪事件列表后批量处理。
事件注册与监听：何时、如何把 fd 加入监控
监听始于 master 进程创建监听 socket（如 listen 80），随后 fork 出 worker 后，每个 worker 都会继承该 socket 并调用 epoll_ctl(EPOLL_CTL_ADD) 将其加入自己的 epoll 实例。
- 新连接到达时，accept() 返回客户端 socket，Nginx 立即将其设为非阻塞，并注册到当前 worker 的 event loop 中，关注 EPOLLIN（可读）事件
- 当需要发送响应数据且发送缓冲区未满时，注册 EPOLLOUT；若发送中遇到 EAGAIN/EWOULDBLOCK，则临时启用 EPOLLOUT 等待可写
- 定时器事件（如连接超时、请求体读取超时）由 Nginx 自维护红黑树管理，EventLoop 每次迭代前检查是否到期
事件分发与回调：从就绪 fd 到具体 handler
EventLoop 获取到就绪事件后，并不直接执行业务逻辑，而是将事件封装为 ngx_event_t 结构，交由对应的事件 handler 处理：
- 监听 socket 的就绪事件 → 触发
ngx_event_accept，调用 accept() 接收新连接并创建新连接对象ngx_connection_t - 客户端 socket 可读 → 调用
rev->handler，通常是ngx_http_init_request（首次请求）或ngx_http_process_request_line（后续读取） - 客户端 socket 可写 → 调用
wev->handler，如ngx_http_writer发送响应体 - 所有 handler 均运行在当前 worker 的单一线程上下文中，无锁设计依赖事件分离与状态机驱动
关键设计特点：轻量、状态化、无栈切换
Nginx 的 EventLoop 不做协程调度，也不维护用户态栈，每个连接对应一个 ngx_connection_t 和一组 ngx_event_t，通过显式状态字段（如 read->ready、write->ready、connection->data 指向 request 或 upstream）驱动请求生命周期。
这意味着：一次系统调用返回多个就绪事件 → 批量处理；每个事件处理函数短小、快速返回 → 避免长时间占用 loop；连接状态保存在内存结构中 → 支持跨多次事件迭代完成复杂流程（如大文件传输、代理转发）。
