Nginx 在 Linux 下依赖 epoll 实现单进程高并发，通过红黑树管理 fd、就绪链表通知事件、mmap 零拷贝提升效率；每个 worker 独立 epoll 实例，配合 multi_accept、accept_mutex 等配置与非阻塞 IO 保障流水线性能。

Nginx 使用 epoll 作为 Linux 下默认的事件驱动模型，是其单进程高并发能力的核心支撑。它不靠多线程或多进程横向扩展，而是通过一个 worker 进程高效调度成千上万的并发连接，关键就在于 epoll 的精准就绪通知与零拷贝用户态管理。

epoll 为何比 select/poll 更适合高吞吐场景

select 和 poll 每次调用都要遍历全部文件描述符（fd）集合，时间复杂度 O(n)，且需在内核与用户空间反复拷贝 fd 集合；而 epoll 采用红黑树 + 就绪链表结构：

• epoll_ctl() 一次性注册 fd，内核维护红黑树，增删改 O(log n)
• epoll_wait() 只返回已就绪的 fd 列表，无须轮询，时间复杂度接近 O(1)
• 就绪事件通过内存映射（mmap）共享，避免 fd 集合拷贝开销

worker 进程与 epoll 的协同机制

Nginx 启动时按 worker_processes auto 或显式配置生成固定数量的 worker 进程，每个进程独立绑定一个 epoll 实例，互不干扰：

• 每个 worker 循环执行 epoll_wait()，等待任意 socket 就绪（accept、read、write 等）
• 事件就绪后，立即调用对应 handler（如 ngx_http_init_request），全程非阻塞
• 请求处理中若需读取文件、转发 upstream，仍通过 epoll 监听后续 IO 就绪，不阻塞主线程

关键配置项强化 epoll 效能

仅启用 epoll 不够，还需配合以下设置释放其潜力：

• worker_connections：单个 worker 能同时处理的最大连接数，建议设为系统允许上限（ulimit -n 值的 70%~90%，避免资源耗尽）
• use epoll：显式声明（虽 Linux 默认启用，但明确写出可提高可读性与兼容性）
• multi_accept on：让一个 epoll_wait() 尽可能 accept 多个新连接，减少事件循环空转
• accept_mutex on（默认）：避免惊群，确保同一时刻仅一个 worker 竞争新连接

避免阻塞操作破坏 epoll 流水线

epoll 高效的前提是所有 IO 都保持非阻塞。常见破坏点包括：

• 上游代理未配置 proxy_buffering off 或缓冲区过小，导致 write 阻塞
• 静态文件未启用 sendfile on，绕过用户态拷贝，直接由内核 DMA 传输
• 日志写入未用 buffered logging（access_log ... buffer=64k flush=5s），频繁磁盘 sync 打断事件循环
• 自定义模块调用同步 DNS 解析（如 gethostbyname）、阻塞文件读写等