Nginx 的非阻塞 I/O 是其应对突发流量的底层根基，依赖内核参数调优（如 somaxconn）、Nginx 配置（backlog、multi_accept、proxy_buffering）及上游策略（timeout、limit_req、keepalive）协同实现全程无等待。
Nginx 的非阻塞 I/O 不是“锦上添花”的可选项，而是它扛住突发流量的底层根基。它的表现不靠单点优化，而在于整条链路——从连接接入、事件调度到上游转发——全程无等待、无卡顿、无资源浪费。
连接层：毫秒级建连，拒绝丢包
突发流量最先冲击的是 TCP 连接建立环节。非阻塞 I/O 配合 epoll/kqueue，让 worker 进程在 accept() 时不会被阻塞，但前提是内核层面不能丢连接。
- 必须调大
net.core.somaxconn和net.ipv4.tcp_max_syn_backlog至 65535 - Nginx
listen指令要显式写backlog=65535（默认仅 511，极易溢出） - 压测中用
ss -lnt观察Recv-Q，持续大于 0 就说明队列已满、连接正被内核丢弃
事件调度层：单 worker 管数万连接，CPU 不空转
一个 worker 进程不依赖线程切换，而是靠事件循环轮询就绪 socket：
- 数据未就绪时
recv()立即返回EWOULDBLOCK，进程立刻处理下一个事件 - 内核通过
epoll_wait主动通知“哪个连接可读/可写”，避免轮询开销 -
multi_accept on让一次事件唤醒能批量接收多个新连接，减少空转次数 -
worker_cpu_affinity auto把每个 worker 绑定独立 CPU 核心，缓存更稳定
上游转发层：不因后端慢而卡住 clientproxy_pass 本身非阻塞，但若不加约束，慢后端会把 worker 拖入“等响应”状态：
- 开启
proxy_buffering on，配合proxy_buffers 8 16k和proxy_busy_buffers_size 32k，把响应体暂存内存或磁盘 - 设置
proxy_read_timeout 15和proxy_send_timeout 15，防僵死连接长期占位 -
limit_req burst=50 nodelay配合proxy_next_upstream error timeout http_500–504 tries=2，超限立即返回 503，失败请求快速切节点，不排队不等待
长连接与业务适配：避免隐式阻塞
物联网或 WebSocket 场景下，单连接可能持续数小时，此时：
- 不要用
limit_conn粗暴限制总连接数，改用limit_req按$http_upgrade或$connection分类限频 -
keepalive_timeout 15s+keepalive 32加速连接复用 - 避免在
location中使用auth_request或复杂 Lua 脚本做实时鉴权——它们可能同步阻塞事件循环，应改用auth_jwt或前置网关处理
非阻塞 I/O 的价值，不在代码里多写一行配置，而在整个系统节奏的改变：从“等数据就绪”变成“等内核通知”，从“被动挂起”变成“主动响应”。只要内核参数、Nginx 配置、上游策略三者对齐，突发流量来了，连接照建、请求照转、响应照发，稳而不僵。
