Non-blocking I/O是Nginx高并发能力的底层基石，通过O_NONBLOCK标志使I/O调用立即返回，结合epoll事件驱动模型，避免进程阻塞，显著降低CPU切换、内存栈开销和连接等待损耗，并需配套配置worker_connections、multi_accept、worker_rlimit_nofile及CPU亲和性等参数以充分发挥性能。
Non-blocking IO 是 Nginx 高并发能力的底层基石，它让单个 worker 进程能高效调度数万连接，而不是靠堆线程或进程硬扛流量。
为什么 Non-blocking IO 能应对高流量
传统阻塞 I/O 在 read()/write() 时会停住进程，等数据就绪或缓冲区腾出空间；而 Nginx 在 socket 上启用 O_NONBLOCK 标志后，调用立即返回：有数据就读，没数据就返回 EAGAIN/EWOULDBLOCK，绝不空等。配合 epoll（Linux）或 kqueue（BSD），系统只在“可读”“可写”“断连”等事件触发时通知 Nginx，worker 进程全程不阻塞、不挂起。
这直接规避了三类开销：
- CPU 不再浪费在线程切换和上下文调度上
- 内存不再被大量线程栈占用（每个线程默认占几 MB）
- 连接等待 I/O 时，进程仍可处理其他活跃连接
关键配置要匹配 Non-blocking IO 特性
光有非阻塞机制还不够，Nginx 配置需与之协同，否则无法释放全部性能：
- events 块中必须指定 use epoll;（Linux 环境），确保使用高效事件驱动模型，而非过时的 select/poll
- worker_connections 应设为接近系统 ulimit -n 的值（如 65535），否则连接数未达瓶颈，文件描述符先耗尽
- multi_accept on; 让 worker 一次性从内核接收多个就绪连接，减少事件循环轮询次数，吞吐提升约 20%
- accept_mutex off; QPS 超过 5000 后建议关闭，避免 worker 争抢新连接锁造成延迟
系统级支撑不可忽略
Nginx 的 Non-blocking IO 效果依赖操作系统底层支持：
- 确认系统最大文件描述符数足够：ulimit -n 至少设为 65535，并在 /etc/security/limits.conf 中对 nginx 用户或 root 持久化设置 soft/hard nofile
- worker_rlimit_nofile 必须在 nginx.conf 全局块中显式声明，否则 worker 进程无法突破默认限制（通常仅 1024）
- 开启 CPU 亲和性（worker_cpu_affinity auto）可减少 cache miss，让每个 worker 绑定独立核心，更稳定地发挥非阻塞并发优势
验证是否真正启用 Non-blocking IO
运行 nginx -V 2>&1 | grep -o with-http_ssl_module 只能看出模块编译情况，真正确认需结合：
- 检查 nginx.conf 中 events → use 是否为 epoll/kqueue
- 用 ss -ant | wc -l 观察 ESTAB 连接数是否轻松突破万级
- 监控单个 worker 进程 CPU 使用率——若长期低于 70%，说明事件驱动+非阻塞调度运转良好；若持续满载，则需排查业务逻辑或上游瓶颈
