nginx高效率转发能力根本源于异步事件驱动架构，即单worker进程通过epoll/kqueue等机制统一调度万级并发连接，配合零拷贝、内存池、连接复用及异步健康探测等优化，实现低延迟、高吞吐、低资源消耗的反向代理。
Nginx 的高效率转发能力，根本上来自其异步事件驱动架构——它不靠堆线程或进程，而是让单个 worker 进程通过操作系统内核的高效通知机制，同时调度成千上万的连接。
单 worker + 事件循环统一调度
每个 worker 进程运行一个轻量级事件循环，不主动轮询也不阻塞等待。它调用 epoll_wait（Linux）或 kqueue（macOS/FreeBSD），交由内核告知“哪些 socket 就绪”。一旦有客户端发来请求、后端返回响应、或连接关闭，就立即触发对应回调处理。整个过程在用户态内存中快速完成，不因某个慢请求卡住其他连接。- 新连接建立、HTTP 头解析、proxy_pass 转发、响应写回，都拆解为独立事件注册进循环
- 没有请求时，worker 不空转，CPU 时间自动让给其他就绪任务
- 相比 Apache 的 prefork 模型，万级并发下内存占用更低、上下文切换更少
零拷贝与内存池减少数据搬运开销
转发过程中，Nginx 尽量避免数据在内核态和用户态之间反复复制：- 静态文件响应启用 sendfile()，让内核直接从磁盘读取并写入 socket 缓冲区，跳过用户空间
- 动态响应使用 slab 内存池管理 request/response buffer，减少 malloc/free 频次和内存碎片
- 通过 TCP_NOPUSH（合并小包）和 TCP_NODELAY（禁用 Nagle 算法）控制网络层行为，适配不同业务节奏
上游连接复用与健康探测异步化
反向代理场景中，Nginx 把与后端的交互也纳入事件流，避免同步等待拖慢整体链路：- upstream 块中配置 keepalive 32，复用 TCP 连接承载多个请求，省去重复握手和慢启动
- health_check 指令发起的探测是异步的，不阻塞主请求流；失败时自动剔除节点，恢复后平滑加回
- request queue 机制可在后端繁忙时暂存请求，而非立刻返回 502，提升容错能力
配置必须匹配事件驱动逻辑
异步能力不会自动生效，需针对性配置才能释放全部潜力：- worker_processes 设为 CPU 核心数（如 auto），避免过多进程争抢事件队列
- worker_connections 设置足够高，并同步调整系统 ulimit -n 和 fs.file-max
- proxy_buffering 开启可缓冲后端慢响应，防止客户端长等；buffer 大小需按典型响应体预估
- 避免在 proxy_pass 前使用复杂 rewrite 或正则 location，否则会在事件处理路径中引入隐式延迟
不复杂但容易忽略。
