Nginx用非阻塞I/O解决的不是“能不能快”，而是“会不会崩”：通过O_NONBLOCK标志使I/O调用立即返回EAGAIN/EWOULDBLOCK，杜绝进程挂起；再结合epoll事件循环只处理就绪fd，并辅以worker_connections限流、分级超时等机制，确保万级并发下不卡顿、不假死、不雪崩。
Nginx 用非阻塞 I/O（Non-blocking I/O）解决的不是“能不能快”，而是“会不会崩”——它让单个 worker 进程在万级连接下依然不卡顿、不假死、不因个别慢请求拖垮整体。
Non-blocking IO 是稳定性的底层锚点
传统阻塞模型中，一次 read() 或 write() 调用若遇数据未就绪或缓冲区满，进程会直接挂起；而 Nginx 在 socket 上强制设置 O_NONBLOCK 标志，所有 I/O 操作立即返回：有数据就读走，没数据就报 EAGAIN/EWOULDBLOCK，绝不等待。这从源头上杜绝了线程/进程被单个慢连接长期占用的情况。
- 哪怕后端 upstream 响应延迟 5 秒，Nginx worker 也不会停在这儿干等，而是立刻转去处理其他就绪事件
- 磁盘日志写满、客户端网络抖动、TLS 握手慢……这些常见异常都不会导致整个 worker 阻塞
- 没有阻塞，就没有“雪崩式”资源耗尽——内存不会因堆积线程栈而爆掉，CPU 不会在调度空转中浪费 cycles
与事件循环协同，形成稳态调度闭环
Non-blocking 只是前提，真正维持高并发稳定运行的是它和 epoll/kqueue 事件循环 的绑定：
- worker 启动后，所有 client socket 和 upstream socket 全部注册进 epoll
- 每次 epoll_wait() 只返回当前可读/可写的 fd 列表，Nginx 仅对这些就绪项执行轻量回调
- 每个回调函数（如 ngx_http_process_request）执行完即退出，不嵌套阻塞调用，也不主动 sleep
- 若某请求需等待下游响应，Nginx 不会轮询，而是把该连接重新挂回 epoll，等事件再次就绪再唤醒
避免资源耗尽的关键设计细节
稳定性不仅靠机制，更靠约束。Nginx 在 Non-blocking 基础上叠加了多重防护：
-
连接数硬限：通过
worker_connections控制单 worker 最大并发连接数，防止 epoll 监听列表溢出 -
超时分级控制：
client_header_timeout、send_timeout、proxy_read_timeout等独立设限，避免某类慢请求无限占位 -
缓冲区预分配：
client_header_buffer_size和large_client_header_buffers避免频繁 malloc/free 引发内存碎片或锁争用 -
日志异步刷盘：启用
access_log /path.log buffer=64k flush=1s，将写日志从主线程剥离，防止磁盘 I/O 拖慢事件循环
对比 Apache：稳定性的分水岭在哪？
Apache 的 prefork 或 worker 模型本质是“连接即资源”：一个连接对应一个进程或线程，只要连接存在，资源就持续占用。而 Nginx 是“连接即事件”：
- 1 万个空闲长连接，在 Apache 中意味着 1 万个线程常驻内存；在 Nginx 中只是 epoll 表里的 1 万个 fd，几乎零开销
- 突发流量打进来，Apache 可能因 fork 失败或线程创建失败直接拒绝服务；Nginx 只需在 epoll 中注册新 fd，响应延迟可控
- 某个恶意客户端持续发送半包或慢速攻击，Apache 线程会被钉死；Nginx 依靠超时+非阻塞，几秒内自动清理无效连接
