如何优化Nginx的ngx_event_timer_rbtree以高效管理百万级长连接超时？

本文共计1170个文字，预计阅读时间需要5分钟。

Nginx的`ngx_event_timer_rbtree`无法支持百万级长连接+每连接多定时器的超时管理场景；它仅确保每个连接挂起时仅有一个超时节点，百万级连接的超时检查仍在线性时间复杂度内完成。

红黑树结构绑定的是 ngx_event_t，不是业务任务

你不能把任意定时逻辑塞进 ngx_event_timer_rbtree——它的每个节点必须是 ngx_event_t 结构体内的 timer 字段，而该结构体又必须依附于某个真实网络事件（如 client connection、upstream connection 或 listen socket）。这意味着：

• 没有独立的“定时任务对象”，所有定时器都强耦合在连接/事件生命周期上
• ngx_add_timer() 必须传入一个已初始化的 ngx_event_t*，且该 event 的 data 字段通常指向 ngx_connection_t 或 ngx_http_request_t
• 一旦连接关闭（ngx_close_connection()），其关联的 timer 若未手动 ngx_del_timer()，会引发 use-after-free 或红黑树损坏
• 红黑树中节点数 ≈ 当前活跃连接数（前提是每连接最多注册一个超时）

ngx_event_expire_timers() 是单线程同步遍历，不支持耗时回调

这个函数在 event loop 主线程中被调用，它从红黑树最小节点开始逐个检查、触发、删除。关键限制在于：

• 遍历过程不 yield，若某个 ev->handler() 执行超过几毫秒（比如做了阻塞 I/O、复杂计算或调用了 sleep()），整个 worker 就卡住，后续所有网络事件（包括新连接、读写）全部延迟
• 没有任务队列缓冲，也没有异步分发机制；超时回调就是直接函数调用
• 即使你用 ngx_post_event() 把逻辑推到 posted queue，也需确保 event 对象生命周期可控——而连接可能已在 handler 中被 close
• 典型安全做法：只在 handler 中做标记（如置 c->timedout = 1）、清理资源、调用 ngx_close_connection()，其他逻辑移交 downstream request 或 upstream state 机制处理

timer_resolution 配置会彻底改变超时检测模型

是否设置 timer_resolution 指令，决定了 Nginx 如何与底层事件引擎（epoll/kqueue）协同等待超时：

• 未设 timer_resolution：epoll_wait 使用动态 timeout，值来自 ngx_event_find_timer() 计算出的“最近超时时间差”，精度高、无信号开销，但要求每次 epoll_wait 返回后都调用 ngx_event_expire_timers()
• 设了 timer_resolution 100ms：Nginx 启动 SIGALRM 定时器，每 100ms 触发一次 ngx_timer_signal_handler，强制唤醒 event loop 并检查红黑树——此时 epoll_wait 的 timeout 设为 NGX_TIMER_INFINITE，完全依赖信号中断
• 后者在高并发下会产生大量信号上下文切换，且超时精度被钉死在 100ms 级别，可能导致本该 5ms 到期的连接被拖到 100ms 后才清理
• 生产环境几乎从不启用 timer_resolution，除非你在调试或需要粗粒度周期扫描（如自定义健康检查）

百万连接 ≠ 百万定时器节点，但误用会导致红黑树退化

红黑树操作本身是 O(log n)，但前提是你没破坏它的使用契约：

• 每连接反复 ngx_add_timer() / ngx_del_timer()（比如心跳续期）没问题，只要确保旧 timer 已删、新 timer 正确插入
• 若忘记 ngx_del_timer() 就重用同一 ngx_event_t 插入新超时，会导致红黑树节点重复插入，触发断言失败或崩溃（ngx_rbtree_insert_timer_value 不检查重复 key）
• 若在 handler 中未清空 ev->timer_set = 0，下次误调 ngx_del_timer() 会尝试从树中删一个不在树里的节点，造成内存越界
• 真正压垮性能的不是树大小，而是错误导致的节点泄漏——树节点长期堆积，ngx_event_expire_timers() 遍历耗时从微秒级升至毫秒级，最终拖慢整个 worker

实际线上跑百万连接时，最常被忽略的是 timer 生命周期与 connection/request 生命周期的严格对齐——这不是配置问题，是 C 层内存契约问题。