Nginx的Event Loop是由worker进程、epoll、ngx_event_t结构体、就绪队列与同步回调链、定时器红黑树共同构成的确定性调度系统；每个worker为单执行流进程，通过同步调用ngx_process_events_and_timers()驱动循环，依赖epoll高效获取就绪事件，以ngx_event_t统一封装事件及回调，就绪后同步执行handler，定时器由各worker独立维护的红黑树管理，全程无线程切换与隐式调度。
Nginx 的 Event Loop 不是抽象概念，而是由几个紧密协作、职责明确的运行时组件共同构成的确定性调度系统。它不依赖线程切换或异步中断，靠的是每个 worker 进程内同步执行的一套闭环逻辑。
worker 进程：事件循环的唯一载体
每个 worker 是一个独立的 Unix 进程，内部只有一条执行流。Event Loop 就运行在它的主函数里（ngx_worker_process_cycle），持续循环调用 ngx_process_events_and_timers()。它不为连接开线程，也不共享连接状态——这意味着 10 万个连接，只需 4–8 个 worker，没有跨进程锁和上下文切换开销。
epoll（或 kqueue/iocp）：内核级事件通知引擎
Linux 下默认且推荐使用 epoll，它让 Nginx 能以 O(1) 复杂度监听成千上万个 fd。worker 调用 epoll_wait() 阻塞等待，超时时间由定时器系统动态计算；返回后仅获取就绪事件列表，不读数据、不解析协议，只做搬运。这个“拉取式”设计把控制权牢牢掌握在 Nginx 自己手中，避免被内核回调打乱节奏。
ngx_event_t 结构体：事件注册与回调的统一载体
所有事件（读、写、定时器、清理）都封装成 ngx_event_t 实例。关键字段有两个：
-
handler存函数指针，比如ngx_http_process_request_line或ngx_event_accept -
data存关联对象指针，通常是ngx_connection_t*或ngx_http_request_t*
注册不是静态配置，而是在连接生命周期中动态完成：监听 socket 初始化时挂 accept handler，accept 后挂 HTTP 请求解析 handler，发响应前才挂 writer handler。
就绪队列与同步回调链：可控、可预测的执行路径epoll_wait 返回后，Nginx 把内核就绪事件翻译成 ngx_event_t* 并填入就绪队列（如 ngx_cached_ready_events）。接着主循环遍历该队列，对每个有效事件直接调用 ev->handler(ev)。整个过程完全同步：当前 worker 阻塞在此调用，直到 handler 执行完毕；handler 内部决定是否继续注册新事件、是否关闭连接、是否触发 upstream，逻辑清晰、无隐式调度。
定时器红黑树：超时管理与事件循环深度整合
所有超时（keepalive、read_timeout、proxy_timeout 等）都插入同一个最小堆（实际用红黑树实现），每次事件循环迭代前先调用 ngx_event_expire_timers() 扫描并触发到期定时器。定时器不是独立线程，也不发信号，它和 I/O 事件共用同一调度节奏，且每个 worker 维护自己的 timer heap，天然隔离无竞争。
