non-blocking i/o 是 nginx 高并发低延迟的核心机制，通过事件驱动使单 worker 进程高效管理数万连接，避免线程阻塞与资源浪费，并需配合 epoll、worker_connections、keepalive 等配置优化。
Non-blocking I/O 是 Nginx 在高负载下保持低延迟、高吞吐的核心机制，它不依赖线程或进程阻塞等待数据就绪，而是让单个工作进程持续轮询或监听多个连接的状态变化，从而用极少资源处理数万并发连接。
为什么 Non-blocking I/O 能扛住高并发
传统阻塞式 I/O（如 Apache 的 prefork 模型）中，每个连接需独占一个线程/进程，连接数一多，上下文切换和内存开销就急剧上升。而 Nginx 的 Non-blocking I/O 配合事件驱动模型，使一个 worker 进程可同时管理成千上万个 socket 连接——只要内核通知“这个连接有数据可读/可写”，Nginx 就立即处理，其余时间不空等。
- 避免线程创建销毁开销，节省 CPU 和内存
- 减少系统调用次数（如 epoll_wait 一次返回多个就绪事件）
- 连接生命周期内无需反复分配/释放资源，提升复用率
关键配置如何强化 Non-blocking 行为
默认情况下 Nginx 已启用 Non-blocking I/O，但必须配合合理参数才能发挥全部潜力：
-
events 块中明确指定高效事件模型：Linux 环境下固定用
use epoll;，避免回退到低效的 select/poll -
worker_connections 设置需匹配实际承载能力：例如 12 核服务器设
worker_processes 12，每个 worker 设worker_connections 32768，总连接能力约 39 万，但要确保worker_rlimit_nofile≥ 该值，否则内核拒绝新建连接 -
关闭阻塞式行为倾向：禁用
accept_mutex off;（高并发时减少锁争用），并开启multi_accept on;，让单次事件触发尽可能多地接受新连接
与上游服务协同，避免 Non-blocking 被“打断”
即便 Nginx 自身是非阻塞的，若上游（如后端应用）使用短连接或响应慢，Nginx 可能被迫长时间等待，变相引入阻塞。因此必须配套优化：
- 在 upstream 中启用长连接池：
keepalive 200;，并设置proxy_http_version 1.1;和proxy_set_header Connection ""; -
proxy_read_timeout应略小于后端 keepalive timeout（如后端设 60s，Nginx 设 55s），防止连接被单方面关闭导致资源滞留 - 搭配
least_conn或ip_hash负载策略，避免某台后端因连接堆积而拖慢整体响应
缓冲区与日志控制，防止 Non-blocking 被内存拖累
Non-blocking I/O 的高效依赖于快速完成数据拷贝和状态切换。过大的缓冲区或频繁日志写入会引发内存抖动或磁盘 I/O 阻塞，间接削弱非阻塞效果：
- 收紧请求头缓冲：
client_header_buffer_size 1k;，large_client_header_buffers 2 2k; - 限制请求体大小：
client_max_body_size 50m;，防止单个大上传耗尽 worker 内存 - 全局关闭访问日志：
access_log off;；仅对调试路径或核心接口单独开启
