nginx通过异步事件驱动实现高并发：单worker拆解请求为独立事件，非阻塞处理连接、请求与响应各阶段，并协同系统避免隐性阻塞，以最大化单位时间就绪事件处理量。
Nginx 的异步事件驱动架构不是靠“多线程抢资源”来应对高并发，而是让单个 worker 进程像一个高效调度员，把成千上万个请求的每个环节——连接建立、读头、转发、收响应、写回——都拆成独立事件，只在真正就绪时才处理，全程不阻塞、不空等。
连接建立阶段：减少争抢与延迟
新连接到来时，Nginx 通过 multi_accept on 让 worker 一次接收多个已就绪连接，避免反复进出事件循环；用 accept_mutex on（默认）确保同一时刻仅一个 worker 尝试 accept，防止“惊群”唤醒开销；每个连接还携带唯一 instance 标志，彻底规避刚关闭又复用 socket 导致的串话问题。
请求处理阶段：解耦与非阻塞执行
HTTP 请求被划分为多个阶段（如读取 header、解析 URI、匹配 location、调用 upstream），每个阶段注册为独立回调。事件循环只负责派发，模块只做轻量操作：
- 头部解析在内存中快速完成，不涉及磁盘或网络等待
- 静态文件直接走
sendfile()，内核零拷贝直达 socket - 动态请求转发给后端时，连接复用 keepalive，避免重复握手和慢启动
- 所有 I/O 操作基于非阻塞 socket，
read()/write()立即返回，失败时仅记录并继续处理其他事件
响应返回阶段：合并、缓冲与精准超时
- 启用
tcp_nopush on，让内核攒够 TCP 包再发，减少小包数量；配合tcp_nodelay off（默认）平衡吞吐与延迟 - 对客户端响应启用
keepalive_timeout和keepalive_requests，控制长连接生命周期，防慢客户端长期占位 - 每个连接的读写超时（如
client_header_timeout、proxy_read_timeout）独立计时，避免一个卡顿请求拖垮整条流水线
系统协同层面：避免隐性阻塞点
事件驱动再高效，也救不了下游的同步瓶颈：
- 日志写入需开启
buffered或异步日志模块，否则access_log可能成为 I/O 瓶颈 - SSL 握手建议启用
ssl_session_cache和合理ssl_buffer_size，减少加解密重复开销 - Lua 脚本若含阻塞调用（如
os.execute、同步http.request），会锁死整个 worker，应改用 cosocket 或移至后端处理 -
worker_processes auto+worker_cpu_affinity auto让进程数与 CPU 核心对齐，减少上下文切换
本质上，这条请求链路的优化逻辑很清晰：把等待变成注册、把阻塞变成回调、把串行变成事件流水线。它不追求单次操作最快，而是让单位时间里处理的就绪事件最多——这才是十万并发下依然低延迟的底层原因。
