Nginx的ngx_event_timer_rbtree仅支持每连接一个定时器，不适用于百万级长连接多定时器场景；其节点绑定ngx_event_t且强耦合网络事件生命周期，超时回调同步执行、无缓冲队列，timer_resolution启用会导致精度下降与信号开销。
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 层内存契约问题。
