nginx 高性能源于单 worker 进程 + 异步事件驱动模型，依托 epoll 实现 o(1) 就绪检测、零拷贝与长效事件注册，并通过非阻塞 i/o 和合理配置（如 worker_processes auto、sendfile on）最大化资源利用率。
Nginx 的高性能不靠堆线程或进程，而是靠单 worker 进程 + 异步事件驱动模型把系统资源用到极致。它让一个进程同时盯住成千上万个连接，只在真正有事（比如数据来了、能写了、出错了）时才动手，其余时间不空转也不阻塞。
epoll 是 Linux 下高效监听的核心
在 Linux 环境中，Nginx 默认或显式启用 epoll 作为事件通知机制。它不像 select/poll 那样每次都要遍历所有文件描述符，而是内核维护一个就绪队列，worker 调用 epoll_wait() 就能直接拿到当前活跃的 socket 列表。这意味着： • 即使打开 10 万个连接，检测谁就绪也几乎是 O(1) 开销 • 没有重复拷贝 fd 集合，减少用户态与内核态之间数据搬运 • 事件注册一次后长期有效，避免反复调用系统接口
事件循环是 worker 的唯一主干
每个 worker 进程启动后就进入一个永不退出的循环，核心逻辑是： • 等待 epoll_wait 返回就绪事件 • 遍历这些事件，区分读、写、错误等类型 • 分发给对应 handler：比如 ngx_http_wait_request_handler 处理新连接，ngx_http_read_client_request_body 处理 POST 数据 • 处理完立刻回到等待状态，不 sleep、不轮询、不阻塞其他连接
非阻塞 I/O 让单进程不卡死
所有 socket 都设为非阻塞模式。比如读取请求头时，若数据没收全，recv() 返回 EAGAIN/EWOULDBLOCK，worker 就先记下这个连接，继续处理别的事件；等下次 epoll 通知可读了再回来接着读。这种“中断-恢复”机制保证： • 一个慢连接不会拖垮整个 worker • 请求头解析、静态文件 sendfile、上游转发等阶段都能被拆成多个事件片段 • 内存中完成大部分操作，避免频繁陷入内核
配置要配合事件模型才能释放潜力
光有异步模型不够，还得通过配置让它真正跑起来： • worker_processes auto —— 匹配 CPU 核心数，避免过度争抢 • worker_connections 65535 —— 配合 ulimit -n 调高系统限制 • multi_accept on —— 一次 accept 多个新连接，减少事件循环唤醒次数 • use epoll —— 显式指定（虽多数情况自动选对，但容器或旧内核里建议写明） • sendfile on 和 tcp_nopush on —— 静态响应走零拷贝路径，减少内存搬运
