Nginx采用Master-Worker多进程与异步非阻塞事件驱动架构：Master进程负责读配置、管理Worker、处理信号及异常拉起；Worker进程独立监听端口，通过epoll处理海量并发连接，全程单线程事件循环，高效低耗。
直接抓住两个关键点：Master-Worker 进程分工 + 事件驱动处理连接，就能快速建立对 Nginx 工作原理的清晰认知。
Master 和 Worker 各自干什么？
启动 Nginx 后，你会看到一个 master 进程 和多个 worker 进程（默认数量等于 CPU 核心数）。它们不是平级协作，而是明确分工：
- Master 进程不碰请求，只做四件事：读配置、管 worker、收信号（比如 reload）、拉起崩溃的 worker；
- Worker 进程才是真正干活的，每个都独立监听相同端口（如 80），但靠内核和 accept-mutex 机制避免“惊群”，确保每次只有一个 worker 成功 accept 新连接；
- 一个连接从接入到响应完成，全程由同一个 worker 处理，不跨进程，也不加锁，既安全又高效。
一个请求进来，Nginx 怎么一步步响应？
这不是线性排队，而是基于事件的调度。整个流程可简化为：
- 客户端发起 TCP 连接，内核通知所有 worker（但仅一个能抢到）；
- 抢到的 worker 把该连接注册进 epoll 事件表，等待“可读”事件；
- 收到 HTTP 请求后，worker 解析 URI，匹配 location 块，调用对应模块（比如静态文件模块或 proxy 模块）；
- 模块处理完成后生成响应，worker 再通过 epoll 触发“可写”事件，把数据发回客户端；
- 连接可能保持（Keep-Alive），也可能关闭，全程不阻塞其他请求。
为什么它比传统服务器更扛并发？
核心差异不在代码多厉害，而在模型选择：
- Apache 是“一个请求一个线程”，1 万并发 ≈ 1 万线程，内存和上下文切换压力巨大；
- Nginx 是“一个 worker 管成千上万连接”，靠 epoll 实现 I/O 多路复用，CPU 不在等待中空转；
- worker 单线程 + 事件循环，没有线程创建/销毁开销，也没有锁竞争，资源利用率高、出错影响小。
动手验证能加深理解
运行 ps -ef | grep nginx 查看进程结构；用 curl -v http://localhost 观察一次请求的完整路径；再修改 nginx.conf 中 worker_processes 或 events { use epoll; } 配置，重启后对比表现——原理就藏在这些动作背后。
