nginx高效源于异步事件驱动架构：基于非阻塞i/o、epoll多路复用、事件循环+状态机处理请求、worker进程隔离与master协调，实现高并发低开销。
Nginx 的高效网络模型，本质是靠异步事件驱动架构撑起来的。它不靠堆线程或进程，而是让少量 worker 进程通过一个事件循环，同时盯住成千上万个连接的状态变化，有事才动手，没事就歇着——CPU 不空转，内存不浪费，上下文切换极少。
非阻塞 I/O 是基础
所有 socket 操作（accept、read、write）都设为非阻塞模式。这意味着：哪怕对端还没发完数据，Nginx 也不会卡在那里干等；调用 read 返回 EAGAIN 或 EWOULDBLOCK，就立刻转向处理别的事件。这种“试一下、不行就走”的方式，保证了单个 worker 始终处于活跃调度状态。
- 系统调用如 recv() 和 send() 都不会导致进程挂起
- 每个连接的读写缓冲区由内存池统一管理，避免频繁 malloc/free
- 配合 SO_REUSEADDR 和 SO_LINGER 等 socket 选项，提升连接复用与释放效率
epoll 是 Linux 下的核心引擎
在 Linux 上，Nginx 默认使用 epoll 实现多路复用。它不像 select/poll 那样每次都要把全部 fd 列表拷贝进内核，而是通过红黑树维护监听集合，只在事件真正发生时通知用户空间。一个 worker 进程靠一个 epoll fd 就能高效轮询数万连接。
- epoll_wait() 阻塞等待就绪事件，返回的是已触发的子集，无需遍历全量 fd
- 事件类型包括 EPOLLIN（可读）、EPOLLOUT（可写）、EPOLLERR（错误）、EPOLLRDHUP（对端关闭）
- Nginx 在源码中通过 ngx_epoll_process_events 函数完成事件分发与回调调度
事件循环 + 状态机驱动请求生命周期
HTTP 请求不是一口气跑完的，而是被拆成多个阶段：TCP 握手完成、请求头接收完毕、后端连接建立、响应体转发中……每个阶段都对应一个事件，注册到事件循环里。Nginx 内部用轻量状态机推进，事件触发就跳转到下一状态，全程无同步等待。
- 例如 proxy_pass 场景下，客户端读事件和上游写事件可并行注册，互不阻塞
- 定时器也集成进事件循环，超时控制（如 client_timeout、proxy_read_timeout）由红黑树高效管理
- 每个请求的 buffer、header、body 解析都在事件回调中完成，不跨事件阻塞主线程
Worker 进程隔离 + Master 协调保障稳定性
Master 进程不碰网络，只做配置加载、worker 生命周期管理和平滑重启；每个 worker 是独立进程，拥有自己的 epoll 实例和内存空间，彼此不共享状态，避免锁竞争。worker 数量通常设为 CPU 核心数，既压满多核，又不过度争抢事件队列。
- 内核通过 SO_REUSEPORT（若启用）或 accept mutex 机制，将新连接均衡分发给各 worker
- worker 异常退出时，master 能立即拉起新进程，服务不中断
- 日志写入、共享内存（如 limit_conn、stub_status）等跨 worker 协作，通过原子操作或文件锁实现低开销同步
