Nginx的Master-Worker架构更稳定，因进程隔离使故障边界清晰：Worker间内存独立，单个崩溃不影响其他进程；Master不处理业务，只负责配置解析、进程管理与信号调度，自身极简可靠；规避了多线程共享内存导致的崩溃扩散、锁竞争与调试困难问题。
Nginx 的 Master-Worker 架构之所以比多线程模型更稳定，核心在于进程隔离性和故障边界清晰。Worker 进程彼此独立、内存不共享，一个崩溃不会波及其他进程；而多线程模型中所有线程共用同一地址空间，任一线程触发段错误或内存越界，整个服务就直接退出。
进程隔离带来天然容错能力
每个 Worker 进程拥有独立的虚拟内存空间、文件描述符和执行上下文。这意味着：
- 第三方模块或 Lua 脚本出错，只会影响当前 Worker，其余 Worker 继续响应请求
- 遇到 SIGSEGV（段错误）或非法内存访问时，操作系统只会终止出问题的那个进程，不会波及 Master 或其他 Worker
- Master 进程能立即检测到子进程异常退出（通过 waitpid 和信号机制），并在毫秒级内拉起新 Worker，用户几乎无感知
Master 不处理业务，专注治理与调度
Master 进程完全不参与网络 I/O、HTTP 解析或磁盘读写等高风险操作，它只做三件事：
- 解析并校验 nginx.conf，确保配置语法与语义合法
- fork 出指定数量的 Worker，并通过信号（如 SIGUSR2、SIGQUIT）控制其启停与重载
- 监听系统信号（SIGHUP 热重载、SIGTERM 安全退出），统一协调全局行为
这种职责分离让 Master 的代码路径极短、逻辑极简，自身崩溃概率极低——它就像一个“守门人”，不碰业务数据，只管秩序。
避免线程模型的共享内存陷阱
多线程模型（如早期 Apache 的 worker MPM）虽然线程创建开销小，但存在根本性风险：
- 所有线程共享堆、全局变量、静态缓冲区，一旦某个模块误写内存（比如越界写入 malloc 分配区之后），可能破坏其他线程的关键数据结构
- 锁竞争在高并发下易引发死锁、优先级反转或性能抖动；而 Nginx 的 Worker 是无锁设计，靠事件循环 + 单线程 + 进程级隔离规避全部锁问题
- 调试困难：线程崩溃后 core dump 往往混杂多个栈帧，难以准确定位源头；而 Worker 崩溃产生的 core 文件只包含单一进程上下文，定位更快
实际运行中的稳定性体现
在生产环境中，这种架构优势直接转化为可观测的稳定性指标：
- 单个 Worker 因正则回溯、SSL 握手异常或 upstream 超时而卡住或退出，不影响其他连接的处理能力
- 执行
nginx -s reload时，Master 启动新 Worker 并逐步移交连接，旧 Worker 在完成已有请求后优雅退出，全程零中断 - 即使配置中误写了一个无限循环的 rewrite 规则，也仅导致该 Worker 在处理特定请求时阻塞，而非整个服务僵死
