nginx 采用多进程架构实现高响应与高可用：每个 worker 进程单线程事件驱动、彼此隔离，通过 accept_mutex 负载均衡；worker 数量匹配 cpu 物理核心并绑定亲和性以优化缓存；总并发连接数 = worker_processes × worker_connections；单 worker 崩溃时主进程毫秒级重启，旧连接平滑关闭、新连接无缝承接。
多进程架构是 Nginx 高响应表现的底层支撑，它不靠单个线程“拼命跑”，而是让多个独立进程并行处理请求，把硬件资源真正用起来，同时规避单点故障带来的延迟抖动。
每个 worker 独立承接连接，避免排队阻塞
主进程只做调度，所有网络 I/O、静态文件读取、SSL 握手、反向代理转发都由 worker 进程完成。每个 worker 是单线程、事件驱动的，但彼此完全隔离——一个 worker 正在处理慢后端响应，不会卡住其他 worker 接收新请求。用户请求进来后，通过 accept_mutex 机制由一个 worker 快速获取连接，立刻进入事件循环，不等待、不排队。
匹配 CPU 物理核心，减少上下文切换开销
worker_processes 设为 CPU 物理核心数（例如 4 核就设 4），再配合 worker_cpu_affinity 绑定到指定核心，能让每个 worker 稳定运行在专属缓存域内，避免跨核迁移导致的 L3 缓存失效。超线程（如 4 核 8 线程）对 Nginx 这类 I/O 密集型服务提升有限，设太高反而增加调度负担，响应延迟反而上升。
并发能力可计算、可预期
总并发连接上限 = worker_processes × worker_connections。只要系统 ulimit -n 足够（比如设为 65535），并配好 worker_rlimit_nofile，Nginx 就能稳定撑住数万级活跃连接。这比单进程+多线程模型更可控——没有锁竞争、没有内存共享、没有 GC 停顿干扰响应时间。
崩溃自动恢复，请求中断率趋近于零
某个 worker 因正则回溯、大文件读取超时或内存分配失败而退出，主进程几毫秒内就能拉起新进程替代。旧连接会按 worker_shutdown_timeout 继续处理完，新连接由其他 worker 或新进程立即承接。整个过程用户无感知，不会出现“正在加载中…突然断连”这类响应中断现象。
