nginx 高效请求处理依赖单 worker 事件循环、非阻塞 i/o、连接复用与零拷贝、模块化设计及上下游协同优化。
Nginx 的高效请求处理不靠堆线程或进程，靠的是把“等待”这件事彻底去掉——用一个 worker 进程，监听成千上万个连接，只在真正有事时才动手。
单 worker + 事件循环：不等、不闲、不切换
每个 Nginx worker 进程启动后就进入一个持续运行的事件循环（event loop），它不轮询、不 sleep，而是调用 epoll_wait()（Linux）这类系统调用，安静等待内核通知：“哪些 socket 准备好了”。一旦收到就绪列表，就挨个处理读写事件——接收请求头、转发给后端、回传响应。整个过程都在内存里快速完成，不阻塞其他连接，也避免了频繁上下文切换。
- 所有 socket 操作都设为非阻塞模式，确保不会卡住循环
- 一个 worker 可同时管理数万连接，CPU 始终处于工作状态，而非空转等待
- 没有为每个请求分配独立线程/进程，内存开销极低
连接复用与零拷贝：省掉重复动作和多余搬运
HTTP 层面启用 keepalive，让同一个 TCP 连接承载多个请求，跳过三次握手和四次挥手；文件传输时用 sendfile()，数据直接从磁盘经内核缓冲区送到 socket，绕过用户态内存拷贝；再配合 TCP_NOPUSH（合并小包）和 TCP_NODELAY（禁用 Nagle 算法），在吞吐和延迟之间动态平衡。
- keepalive 默认开启，建议设置 keepalive_timeout 65;
- 静态资源服务务必开启 sendfile on; 和 tcp_nopush on;
- 对实时性要求高的接口（如 API），可加 tcp_nodelay on;
模块解耦与配置驱动：功能可插拔，行为可调控
Nginx 把事件分发、HTTP 解析、负载均衡、缓存等功能拆成独立模块，核心事件循环只管调度，具体逻辑由各模块注册的回调函数执行。这意味着加功能不影响调度效率，改策略也不用动底层代码。
- 通过 use epoll; 显式启用高效事件模型（Linux 推荐）
- worker_connections 控制单 worker 最大连接数，需与 ulimit -n 匹配
- multi_accept on; 让 worker 一次 accept 多个新连接，应对突发流量
- accept_mutex 控制多 worker 争抢新连接的行为，防“惊群”
异步只是起点，上下游协同才能释放全部能力
Nginx 自身不执行业务逻辑，它的异步模型主要优化 I/O 调度和连接管理。比如处理 FastCGI 请求时，Nginx 异步转发、异步收响应，但 PHP 脚本仍在 php-fpm 里同步执行。如果后端响应慢，Nginx 的连接就会被占着——这时再高的并发能力也发挥不出来。
- 后端需合理配置进程/线程数（如 php-fpm 的 pm.max_children）
- 大 POST 请求要调大 client_body_buffer_size，避免频繁落盘
- 配合 limit_req / limit_conn 做前置限流，防止雪崩
- 日志可异步缓冲：access_log path buffer=32k;
