3. Nginx 架构与进程模型：Master-Worker 模型、多进程与多线程的权衡、事件驱动机制
Nginx 的高并发能力根植于其独特的架构设计。理解 Master-Worker 进程模型、多进程与多线程的权衡以及事件驱动机制，是后续调整调度器参数、优化吞吐量的理论基础。本章将拆解这三个核心设计，并分析它们如何协同工作以支撑百万级并发连接。
3.1 Master-Worker 进程模型
Nginx 采用经典的 Master-Worker 多进程架构。启动后，一个 Master 进程管理多个 Worker 进程，Worker 进程负责实际处理客户端请求。这种设计将管理逻辑与业务逻辑分离，提升了系统的稳定性和可扩展性。
核心优势： Master 进程以 root 权限运行，负责读取配置文件、绑定特权端口、创建/销毁 Worker 进程；Worker 进程通常以普通用户身份运行，处理具体的网络 I/O 和请求转发。即使某个 Worker 进程因 bug 崩溃，Master 进程会立即 fork 出新的 Worker，保证服务不中断。
3.1.1 进程角色与职责
| 角色 | 权限 | 核心职责 | 生命周期 |
|---|---|---|---|
| Master 进程 | root | 读取配置、绑定端口、管理 Worker、处理信号（HUP/USR1/USR2） | 持久运行，直到收到 QUIT/TERM 信号 |
| Worker 进程 | 普通用户（推荐） | 接受连接、处理请求、执行反向代理/静态文件/ FastCGI | 由 Master 创建/销毁，可热升级 |
| Cache Manager 进程 | 普通用户 | 管理磁盘缓存过期与清理 | 按周期唤醒，非持续运行 |
| Cache Loader 进程 | 普通用户 | 启动时将缓存元数据加载到共享内存 | 启动后短暂运行，完成后退出 |
3.2 多进程与多线程的权衡
Nginx 选择多进程而非多线程，是经过深思熟虑的架构决策。这种选择在稳定性、资源隔离和锁竞争方面带来了显著优势，但也牺牲了部分内存共享的便利性。
设计哲学： Nginx 的设计者 Igor Sysoev 认为，对于高并发 Web 服务器，进程级别的隔离比线程级别的共享更重要。一个 Worker 进程的崩溃不会影响其他 Worker，而多线程模型中一个线程的段错误可能导致整个进程退出。
3.2.1 多进程 vs 多线程对比
| 维度 | Nginx 多进程模型 | 传统多线程模型（如 Apache prefork） |
|---|---|---|
| 稳定性 | 高：进程隔离，单个 Worker 崩溃不影响其他 | 低：线程共享地址空间，一个线程崩溃可能导致整个进程退出 |
| 资源开销 | 较高：每个 Worker 有独立内存空间，上下文切换开销大 | 较低：线程共享堆内存，创建和切换成本小 |
| 锁竞争 | 低：Worker 之间通过共享内存通信，大部分操作无锁 | 高：线程间频繁竞争锁，高并发下性能下降明显 |
| CPU 亲和性 | 好：可将每个 Worker 绑定到固定 CPU 核心，减少缓存失效 | 一般：线程可能在不同核心间迁移，L1/L2 缓存命中率降低 |
| 内存共享 | 困难：需通过共享内存 API（slab）实现 | 容易：直接读写全局变量 |
3.2.2 为什么 Nginx 不采用多线程处理请求
Nginx 在 Worker 内部使用完全异步、非阻塞的事件驱动模型，而不是依赖多线程来并发处理请求。这意味着一个 Worker 进程在任意时刻只使用一个 CPU 核心，但通过高效的事件循环可以同时管理数千个连接。
# 典型的 Nginx 配置示例
worker_processes auto; # 自动检测 CPU 核心数
worker_cpu_affinity auto; # 自动绑定 CPU 亲和性
worker_rlimit_nofile 65535; # 每个 Worker 可打开的最大文件数
events {
worker_connections 10240; # 每个 Worker 的最大连接数
use epoll; # Linux 下使用 epoll 事件驱动
multi_accept on; # 一次 accept 多个新连接
}
注意： 虽然 Nginx 主架构是多进程的，但在某些模块（如 upstream 模块的 keepalive 连接池）内部会使用锁和共享内存。这些锁是轻量级的，且只在必要时才竞争，不会成为性能瓶颈。
3.3 事件驱动机制
事件驱动是 Nginx 实现高并发的核心引擎。Nginx 在每个 Worker 进程中运行一个事件循环，通过操作系统提供的异步 I/O 接口（如 epoll、kqueue）来管理数千个 socket 连接，而无需为每个连接创建线程或进程。
3.3.1 事件驱动的工作流程
- 事件收集： Worker 进程调用
epoll_wait()（Linux）或kevent()（FreeBSD），等待内核通知 I/O 事件就绪。 - 事件分发： 根据事件类型（读/写/错误）和关联的 socket 描述符，将事件分发给对应的处理函数。
- 非阻塞处理： 处理函数以非阻塞方式读取请求数据或写入响应数据。如果操作无法立即完成（如后端响应慢），则注册回调并返回事件循环。
- 状态检查： 每次循环末尾检查定时器，处理超时连接、空闲连接关闭等任务。
3.3.2 事件驱动 vs 传统线程池
| 特性 | Nginx 事件驱动 | 传统线程池模型 |
|---|---|---|
| 并发连接数 | 极高（单 Worker 可达 10 万+） | 受限于线程数量（通常数千） |
| 内存开销 | 低：每个连接仅需少量内存（约 2KB） | 高：每个线程需要独立的栈空间（默认 8MB） |
| 上下文切换 | 极少：仅在事件就绪时切换 | 频繁：线程调度导致大量切换 |
| CPU 利用率 | 高效：CPU 主要花在业务处理上 | 低效：大量 CPU 时间花在线程调度和锁竞争上 |
| 编程复杂度 | 高：需使用回调、状态机、非阻塞 I/O | 低：同步阻塞模型，代码直观 |