Nginx无用户可配置的突发事件任务队列，其突发处理依赖分层缓冲与就绪驱动：内核accept队列承载TCP连接，limit_req实现HTTP请求漏桶排队，事件处理基于epoll就绪驱动且无中间任务队列。
Nginx 事件驱动架构本身不提供用户可配置的“突发事件任务队列”，它处理突发请求的方式是分层缓冲与就绪驱动，不是靠维护一个待执行任务列表来排队。
内核连接队列：第一道缓冲
当大量 TCP 连接瞬间抵达，已完成三次握手的连接会先进入操作系统内核的 accept 队列（由 net.core.somaxconn 控制上限）。Nginx worker 不主动拉取，而是等 epoll_wait() 返回就绪事件后，再循环调用 accept() 取出连接。这个队列是真正的“突发承载层”：
- 必须显式在 listen 指令中设置
backlog=65535，否则使用默认极小值（常为 128） - 需同步调大内核参数
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog - 压测时可通过
ss -lnt观察 Recv-Q 是否持续接近设定值，判断是否正在承压
limit_req 的 burst 队列：应用层柔性排队
对已建立连接的 HTTP 请求，Nginx 用 limit_req 模块实现带容量限制的漏桶排队：
-
burst=20表示允许最多 20 个请求暂存等待，按 FIFO 顺序以设定速率（如rate=10r/s）匀速放出 -
delay参数让队列中部分请求动态延迟响应（自动注入X-RateLimit-Delay头），适合容忍短时延的场景 -
nodelay则跳过等待，直接将 burst 内请求交由 worker 处理——本质是把排队压力转移给后端
事件就绪即处理，无中间任务队列
Nginx 不像 Node.js 或 Python asyncio 那样维护 microtask/macrotask 队列。它的“排队感”来自：
- 内核返回的就绪 fd 列表顺序（
epoll_wait()结果） - 每个连接的状态机推进节奏（如读 header → 读 body → 转发 upstream → 收 response）
- 定时器红黑树触发的延迟动作（如空闲连接超时关闭），但不支持自定义异步任务提交
信号与事件隔离处理
突发事件如 SIGHUP（重载）、SIGUSR2（平滑升级）由独立信号线程捕获，仅设全局标志并唤醒主 event loop，不打断当前 I/O 处理流程。主循环在下一轮迭代中检查标志并执行 handler，确保网络事件不被中断。
