Nginx高性能源于四大工程设计：进程职责隔离、单线程事件循环、内核级I/O协作、轻量级资源管理；Master仅加载配置、响应信号、启停Worker，不处理请求；Worker独立运行、绑定CPU核心、使用epoll异步非阻塞处理连接，并通过无锁共享内存协作。
Nginx 多进程架构的高性能，不是靠堆砌概念或抽象模型，而是由几项清晰、可验证的工程设计共同支撑：进程职责隔离、单线程事件循环、内核级 I/O 协作、以及轻量级资源管理。它不追求“运行时节点闭合”这类模糊表述，而是在操作系统约束下做最务实的取舍。
Master 与 Worker 职责彻底分离
Master 进程只做三件事：加载配置、响应信号（如 HUP 重载、TERM 停止）、启停 Worker 进程。它不处理任何网络请求，也不参与连接读写。Worker 进程完全独立运行，彼此不共享内存空间，避免锁竞争和状态同步开销。一个 Worker 崩溃，Master 会立刻拉起新进程，服务不受影响。
- Master 不监听端口、不 accept 连接、不解析 HTTP 请求
- Worker 启动后，各自调用 epoll_wait 等待就绪事件，全程单线程运行
- 进程数量建议设为 CPU 核心数（worker_processes auto），避免上下文频繁切换
每个 Worker 绑定一个 CPU 核心，减少调度损耗
现代 CPU 多核环境下，进程在不同核心间迁移会导致 L1/L2 缓存失效，增加延迟。通过 worker_cpu_affinity 将每个 Worker 固定到指定核心，能显著提升缓存命中率和指令执行效率。
- 推荐配置 worker_cpu_affinity auto，Nginx 自动按最优策略绑定
- 手动配置如 worker_cpu_affinity 0001 0010 0100 1000（4 核）也有效，但需匹配实际物理核心布局
- 配合 worker_rlimit_nofile 65535，突破系统默认文件描述符限制
Worker 内部用 epoll 实现单线程高并发
每个 Worker 是一个异步非阻塞的事件循环，依赖 Linux 的 epoll 机制管理连接。epoll 内部用红黑树维护监听 fd，用双向链表存放就绪事件——Nginx 只消费这个链表，不做构造或维护，极大降低用户态开销。
- accept_mutex 或 SO_REUSEPORT 避免“惊群”，让多个 Worker 公平获取新连接
- 每个连接分配独立内存池，关闭时整块释放，避免频繁 malloc/free
- HTTP 解析、静态文件读取、proxy 转发等都在同一事件循环中完成，无线程切换成本
共享资源仅限必要且可控的范围
Worker 之间不共享连接状态，但可通过有限共享内存协作，比如限流（limit_conn）、缓存元数据（proxy_cache）、SSL 会话复用（ssl_session_cache）。这些共享区域使用原子操作或 slab 分配器管理，不引入复杂同步逻辑。
- 共享内存大小需预估并显式配置（如 limit_conn_zone $binary_remote_addr zone=conn:10m）
- 所有共享访问都基于无锁设计，避免 mutex 竞争成为瓶颈
- Master 不参与运行时共享数据更新，仅在 reload 时刷新共享区结构
