Nginx事件循环采用基于红黑树的定时器管理机制而非传统队列模型，自1.11.4起用红黑树（O(log n)）替代链表（O(n)），通过ngx_process_events_and_timers主动检查超时并协同I/O事件调度。
Nginx 的 Event Loop 并不使用传统单线程 JavaScript 那样的“一个队列 + 一个循环”模型，而是基于操作系统提供的高效 I/O 多路复用机制（如 epoll、kqueue、select）构建的事件驱动架构。它把定时器事件（如连接超时、读写超时、keepalive 超时）统一管理为一种“可快速检索的最小堆”结构，而非轮询或链表遍历。
定时器被组织成红黑树（而非堆）
从 Nginx 1.11.4 开始，定时器（ngx_event_timer_rbtree）底层改用红黑树实现，每个定时器节点按到期时间排序。这样插入、删除、查找最小超时时间的复杂度都是 O(log n)，比旧版的双向链表（O(n) 查最小）高效得多。
- 每个连接（
ngx_connection_t）、请求（ngx_http_request_t）或 upstream 句柄都可能挂载自己的定时器节点 - 定时器节点通过
timer字段链接到红黑树，超时时间以绝对时间（毫秒级ngx_msec_t）存储 - 红黑树根节点保存在全局
ngx_event_timer_rbtree中，由主 event loop 统一维护
Event Loop 主循环中主动检查定时器
Nginx 的 ngx_process_events_and_timers() 是核心调度函数。它不是被动等待，而是在每次 I/O 事件处理前后，主动调用 ngx_event_expire_timers() 检查是否有已到期的定时器。
- 先从红黑树中取出最左节点（即最早到期的定时器），判断是否超时（
now >= timer->key） - 若超时，则调用其关联的 handler（如
ngx_http_set_keepalive或ngx_event_close_timer） - handler 执行后，该节点被自动从红黑树中移除；如果需要重设（如 keepalive 连接续期），则重新插入
- 这个过程会持续直到红黑树最左节点未超时，避免一次循环处理过多过期事件影响响应延迟
超时事件与 I/O 事件协同调度
定时器不是独立线程，也不抢占 I/O 处理。它和 socket 读写事件共享同一个 event loop 线程，靠“事件就绪 + 时间到期”双条件驱动。
- 例如：一个空闲 HTTP 连接设置了 60s keepalive 超时，定时器节点插入红黑树；当无数据到达时，epoll_wait 最多阻塞到该超时时刻（通过
timer参数传入） - epoll_wait 返回后，Nginx 先处理实际就绪的 fd 事件（如有新请求），再立即检查并触发已到时的定时器
- 这意味着：超时精度取决于 epoll_wait 的阻塞时长，而该时长由最近的定时器决定——越近的超时，epoll_wait 阻塞越短，响应越及时
配置项如何影响定时器行为
多个 Nginx 配置指令直接控制不同场景下的定时器设置，它们最终都会生成并插入对应的红黑树节点：
-
client_header_timeout：解析请求头阶段的读超时，超时后关闭连接 -
send_timeout：发送响应时的写超时，超时后关闭连接（注意：仅对未完成的 send 生效） -
keepalive_timeout：空闲连接保持时间，到期后执行 keepalive 关闭逻辑 -
proxy_read_timeout/proxy_send_timeout：upstream 通信阶段的读写超时，各自独立计时
