Nginx通过异步事件驱动模型（如epoll、kqueue）实现高并发QPS，单工作进程可高效处理数千连接；其非阻塞I/O、无频繁上下文切换及合理配置（如worker_processes auto、use epoll）是关键，但需协同内核参数、上下游服务与业务逻辑优化才能释放全部性能。
Nginx 通过异步事件驱动模型（如 epoll、kqueue）避免传统阻塞 I/O 的进程/线程开销，单个工作进程能高效处理成千上万个并发连接，显著提升 QPS。
事件驱动如何减少阻塞
传统 Web 服务器（如 Apache 的 prefork 模式）为每个请求创建新进程或线程，I/O 等待时资源闲置；Nginx 则让一个工作进程持续监听多个 socket，在内核通知有数据可读/可写时才触发回调处理，全程不阻塞等待。
- 依赖操作系统提供的高效事件通知机制（Linux 用 epoll，FreeBSD/macOS 用 kqueue）
- 所有网络操作（accept、read、write）均设为非阻塞模式，配合事件循环调度
- 无频繁的上下文切换和内存分配，CPU 和内存利用率更优
关键配置影响 QPS 表现
异步能力需合理配置才能发挥最大效能：
- worker_processes auto; —— 让 Nginx 自动匹配 CPU 核心数，避免过多进程争抢 CPU
- worker_connections 10240; —— 单个 worker 可处理的并发连接数，需结合 ulimit -n 调整系统文件描述符上限
- use epoll;（Linux 下显式指定）—— 确保启用高性能事件模型（默认通常已自动选择）
- multi_accept on; —— 允许单次事件触发中接受多个新连接，降低事件循环延迟
与同步模型对比的真实瓶颈点
高并发下，QPS 提升不仅靠事件驱动本身，还取决于能否避开其他隐性阻塞：
- 后端服务（如 PHP-FPM、上游 HTTP 接口）若为同步阻塞，会拖慢整个 pipeline
- 磁盘日志写入（access_log）未缓冲或未异步化，可能成为 I/O 瓶颈
- SSL 握手计算密集，建议开启 ssl_buffer_size 和复用 session ticket 减少开销
- 静态文件发送应启用 sendfile on; 和 tcp_nopush on;，绕过用户态拷贝
异步事件驱动是 Nginx 高性能的基石，但真正释放 QPS 潜力，需要从内核参数、Nginx 配置、上下游协作和业务逻辑响应时间多层协同优化。
