non-blocking io通过让单个工作进程不等待i/o完成而立即处理其他就绪事件，结合epoll等事件驱动机制，实现单进程管理数万并发连接。它依赖socket非阻塞设置、内核事件通知、批量事件处理及合理配置（如worker_connections、multi_accept、keepalive等）协同生效。
Non-blocking IO 是 Nginx 实现高并发连接的核心机制之一，它不靠增加线程或进程数量，而是让单个工作进程能同时管理成千上万的连接——关键就在于“不等”。
为什么 Non-blocking IO 能提升并发能力
传统阻塞式 I/O 中，一个连接在等待磁盘读取、后端响应或网络发包时，整个进程会被挂起，无法处理其他请求。而 Nginx 将 socket 设为非阻塞模式后，所有 I/O 操作（如 accept、read、write、sendfile）都会立即返回：成功则继续，失败则返回特定错误码（如 EAGAIN/EWOULDBLOCK），表示“暂时不可用，稍后再试”。Nginx 不会停在这儿，而是立刻转向处理其他就绪事件。
这种行为依赖操作系统提供的高效事件通知机制（Linux 下默认是 epoll），它让 Nginx 可以用极低开销监控数万文件描述符，只在真正有数据可读、可写或连接就绪时才被唤醒处理。
Non-blocking IO 与事件驱动如何配合
- 事件注册 + 状态轮询替代主动等待：Nginx 把每个连接的 socket 注册进 epoll，并标记关注 EPOLLIN（可读）、EPOLLOUT（可写）等事件；系统内核在状态变化时主动通知，Nginx 无需遍历所有连接去“查”谁 ready 了。
- 一次调用处理多个事件：epoll_wait() 一次性返回一批就绪事件，Nginx 在单次循环中批量处理，避免频繁系统调用开销。
- 零拷贝场景下仍保持非阻塞语义：比如用 sendfile() 发送静态文件时，内核直接从磁盘页缓存复制到 socket 缓冲区，全程不经过用户空间；即便底层涉及 DMA 或缓冲区等待，Nginx 依然不会阻塞，而是交由内核异步完成并触发后续事件。
配置层面需配合 Non-blocking IO 的关键项
Nginx 默认启用非阻塞 I/O，但要让它发挥最大效果，还需确保以下配置协同生效：
- worker_processes auto;：让 Nginx 根据 CPU 核心数自动创建 worker 进程，避免单核过载，也防止过多进程争抢 epoll 实例。
- use epoll;（Linux 环境下显式声明）：明确使用最高效的事件模型，避免 fallback 到 select/poll。
- multi_accept on;：允许单个事件循环中尽可能多地接受新连接，减少“惊群”和重复唤醒。
- worker_connections 65536;：结合 ulimit -n 设置，确保每个 worker 能承载足够多的非阻塞连接。
- keepalive_timeout 75; 和 keepalive_requests 100;：合理复用 TCP 连接，减少反复建立/关闭带来的非阻塞上下文切换成本。
常见误用导致 Non-blocking 效果打折
非阻塞本身不是银弹。以下情况会让它“空转”或失效：
- 后端 upstream 使用阻塞式 HTTP 客户端（如未设 proxy_read_timeout 或 timeout 过长），worker 被卡在等待响应上，无法释放去处理其他请求；
- 开启大 buffer（如 client_body_buffer_size）又未配 fastcgi_buffering off 或 proxy_buffering off，导致内存积压、延迟升高，掩盖了非阻塞优势；
- 日志同步写入（access_log /path.log）未加 buffer 或 flush 参数，在高并发下变成 I/O 瓶颈，拖慢整个事件循环；
- 不当使用 rewrite 或复杂的 map 指令，在每次请求中做大量字符串匹配，CPU 占满，事件处理被延后。
Non-blocking IO 不是独立运行的魔法开关，它是整套事件驱动架构里的执行单元。只有当配置、系统参数、上游行为都对齐时，它才能把单 worker 处理上万连接的能力真正兑现出来。
