Nginx任务调度器由事件循环天然承担，遵循“就绪即处理、无等待、零阻塞”原则，统一纳管I/O与定时任务；依赖epoll_wait等内核通知机制，无轮询或sleep；连接状态机自治，多worker无锁并行，配置决定调度边界。
任务调度器在 Nginx 异步事件驱动架构中并非独立组件，而是由事件循环（event loop）天然承担——它不靠线程抢占或优先级队列调度任务，而是以“就绪即处理、无等待、零阻塞”为根本原则，把所有网络 I/O 和定时任务统一纳管。
就绪驱动，拒绝轮询与空等
调度行为完全依赖内核事件通知机制（如 epoll_wait），而非周期性扫描或 sleep-wakeup。worker 进入事件循环后，仅在无就绪事件且无到期定时器时才短暂挂起；一旦有 socket 可读、可写或超时触发，立即唤醒并批量处理。这种设计消除了传统轮询的 CPU 浪费，也避免了主动 sleep 导致的响应延迟。
- epoll_wait 返回的是已就绪 fd 列表，调度器直接遍历该列表，不做任何过滤或排序
- 每个连接的读/写/错误事件被映射到对应 handler 函数（如 ngx_http_wait_request_handler），调度器只负责分发，不参与业务逻辑
- 定时器（如 keepalive 超时）统一由红黑树管理，插入/删除复杂度 O(log n)，到期时作为“伪事件”参与同一轮 dispatch
单线程内状态机推进，连接生命周期自治
每个连接（ngx_connection_t）自带完整状态（如 reading/writing、buffer 偏移、超时时间），调度器不维护全局任务队列，也不跨连接做上下文切换。一次事件触发后，对应连接的状态机向前推进一小步（例如：收到 EPOLLIN → 尝试 recv → 若 EAGAIN 则暂停，保持事件注册；若读完 header → 触发 HTTP 解析回调）。
- 连接结构体在连接池中预分配，生命周期内复用，避免 malloc/free 开销
- 状态迁移由模块回调函数内部控制，例如 upstream 模块决定转发后，自动注册 write 事件等待后端响应就绪
- 没有“任务排队”概念，只有“事件就绪”和“状态待续”，调度器从不主动挂起或唤醒某连接
多 worker 并行无锁，调度边界清晰
Master 进程不参与调度，所有事件分发与处理均由独立 worker 完成。每个 worker 拥有专属 epoll 实例、内存池、连接池和定时器红黑树，彼此不共享关键数据结构。新连接通过 accept 或 reuseport 由内核分发到某个 worker，后续全部事件都在该 worker 内闭环处理。
- accept_mutex 默认关闭（Nginx ≥ 1.11.3），避免多 worker 争抢 listen socket，让内核更高效负载均衡
- worker_processes 设为 CPU 核心数，配合 worker_cpu_affinity 绑定，减少缓存失效与调度抖动
- 模块回调（如 auth_request、proxy_pass）运行在当前 worker 上下文中，不跨进程通信，无锁竞争
配置即策略，调度行为可收敛可控
调度器的行为不是硬编码，而是通过配置项显式约束资源边界与响应粒度，防止异步模型因失控而退化为隐式同步：
- worker_connections 限制单 worker 最大并发连接数，需与 ulimit -n 对齐，否则 accept 失败
- multi_accept on 让单次 epoll_wait 后尽可能多地 accept 新连接，提升突发流量吞吐
- client_header_timeout / proxy_read_timeout 把不确定等待转为确定性释放，避免慢连接长期驻留
- proxy_buffering on 使 upstream 响应可缓冲，解除客户端与后端的强耦合，保障前端连接不被拖慢
