nginx高性能源于多进程架构与epoll机制的分工协作：多进程实现资源隔离与稳定，每个worker单线程事件循环绑定连接；epoll依托红黑树管理监听fd、双向链表分发就绪事件；nginx自身采用轻量协同设计，内存池、异步处理与模块化流水线对齐系统能力。
Nginx 的高性能不依赖“高度闭合的运行时节点模型”这类抽象概念，而是由清晰、稳定、可验证的工程机制支撑：多进程架构与 epoll 内核机制（含红黑树 + 双向链表）各司其职，协同完成高并发请求调度——二者并非“深度结合构建模型”，而是操作系统层与应用层的分工协作。
多进程结构负责资源隔离与稳定性
Master 进程只做配置加载、信号管理、Worker 生命周期控制；Worker 进程彼此独立，不共享内存，避免锁竞争和单点崩溃风险。每个 Worker 是一个单线程事件循环，专注处理本进程绑定的连接。
- Worker 数量通常设为 CPU 核心数，避免上下文切换开销
- 所有 Worker 共享监听 socket（通过 accept_mutex 或 SO_REUSEPORT 协调），但各自维护独立的连接队列和内存池
- 进程间通信仅限于共享内存（如 limit_conn、slab 分配器）或信号，无复杂状态同步
双向链表在 epoll 中承担就绪事件分发
epoll_wait 返回的就绪事件列表，底层由内核用双向链表组织。这个链表只存“已就绪”的 fd 节点，不遍历全部监听项，实现 O(1) 级别事件提取。
- Nginx Worker 调用 epoll_wait 后，直接遍历该链表，逐个处理活跃连接
- 每个就绪事件对应一个已建立的 TCP 连接或监听 socket，Worker 以非阻塞方式读写
- 链表节点生命周期由内核管理，Nginx 不参与构造或维护，仅消费结果
红黑树用于高效管理海量监听 fd
当 Worker 调用 epoll_ctl 添加/删除/修改 socket 时，内核用红黑树索引所有被监控的 fd。插入、查找、删除平均时间复杂度为 O(log n)，支撑十万级连接注册。
- Nginx 在启动或 reload 阶段批量注册监听 socket 和 upstream 连接 fd
- 运行中极少动态增删监听项，红黑树主要用于初始化和配置变更场景
- 它不参与请求处理路径，也不暴露给 Nginx 用户代码，纯内核数据结构
真正关键的是 Nginx 自身的轻量协同设计
所谓“高性能运行时”，本质是三者对齐：进程模型匹配 CPU 资源、epoll 匹配内核 I/O 能力、Nginx 事件循环匹配用户态处理逻辑。没有额外封装层，也没有试图把红黑树或链表“拉进应用层建模”。
- 每个连接分配独立内存池，连接关闭即整体释放，避免频繁 malloc/free
- 请求解析、静态文件读取、FastCGI 转发等均在单次事件循环内异步推进
- 模块化设计让功能插拔不影响核心事件流，Handlers → Filters → Proxies 流水线清晰
