异步事件驱动是Nginx高性能的核心设计，基于epoll+非阻塞I/O+单线程事件循环，配合多worker无锁并行及HTTP/2适配，通过use epoll;、multi_accept on等配置优化落地。
异步事件驱动是 Nginx 实现高性能业务支撑的底层骨架，不是“附加功能”，而是整个请求处理流程的设计原点。它让单个 worker 进程能同时盯住成千上万个连接，不靠堆线程，也不靠阻塞等待，而是靠系统级事件通知 + 非阻塞 I/O + 精简的事件循环来维持高吞吐、低延迟。
核心机制：epoll + 非阻塞 I/O + 单线程事件循环
在 Linux 环境下，Nginx 默认启用 epoll 作为事件分发器。它不像 select/poll 那样每次都要遍历全部文件描述符，而是通过内核就绪列表直接返回活跃事件，时间复杂度接近 O(1)。配合非阻塞 socket，每个读写操作都不会卡住进程——没数据可读？立即返回；数据未发完？只发能发的部分，其余挂起待下次可写事件触发。整个 worker 就在一个 while 循环里反复做三件事：
- 调用 epoll_wait() 等待事件（带超时，避免空转）
- 遍历返回的就绪事件数组
- 根据事件类型（EPOLLIN/EPOLLOUT/EPOLLERR）调用对应模块的回调函数，比如 ngx_http_wait_request_handler 或 ngx_http_write_filter
多 worker 协同：避免锁竞争，实现天然并行
Master 进程仅负责配置加载和 worker 管理，所有请求处理由独立的 worker 完成。每个 worker 拥有专属的事件循环、内存池和连接池，彼此不共享关键资源。这意味着：
- 没有跨进程锁开销，accept() 和连接处理完全并行
- worker_processes 设置为 CPU 物理核心数（或 auto），可充分利用多核算力
- 配合 worker_cpu_affinity 绑定核心，减少缓存失效和调度抖动
支撑现代协议的关键适配
HTTP/2 的多路复用、长连接保活、服务端推送等特性，高度依赖底层事件模型的响应粒度与并发能力。Nginx 的异步事件驱动天然适配这些需求：
- 一个 TCP 连接可承载数百个 HTTP/2 stream，所有 stream 的帧收发都注册为同一 fd 上的不同事件，由同一个 worker 统一调度
- 流级限速、优先级树更新、头部压缩上下文维护，都在事件回调中完成，无需额外线程介入
- reuseport 配合多 worker，让新连接从内核层面就均衡分发，避免 accept 队列争抢
配置落地要点：让理论真正跑起来
光有模型不够，需通过配置激活并优化其表现：
- use epoll; —— 明确指定（虽默认启用，显式声明更稳妥）
- multi_accept on; —— 让单次 epoll_wait 后尽可能多地 accept 新连接，减少系统调用次数
- accept_mutex off; —— 关闭连接争抢互斥锁（Nginx ≥ 1.11.3 默认关闭）
- worker_connections 65535; —— 结合 ulimit -n 和 fs.file-max 调整系统限制
- access_log ... buffer=64k flush=1s; —— 日志异步缓冲，避免 write() 阻塞事件循环
