架构与请求处理

进程模型

Master Process 读取和验证配置、打开 Listen Socket、管理 Worker，并处理 Reload 等控制信号。Worker Process 执行实际请求处理。

Worker 是长期运行的进程，不是每收到一个客户端连接就由 Master 创建一个新 Worker。每个 Worker 通过 Event Loop 和平台 I/O Mechanism 管理大量 Connection；Linux 常用 epoll，其他系统可能使用 kqueue 等机制。

Event-driven 不等于没有阻塞

事件驱动主要避免为每条 Connection 分配一个 Thread。若 Module 执行阻塞磁盘 I/O、同步 DNS Resolution、复杂脚本或长时间 CPU 运算，Worker 仍会被阻塞，从而影响该 Worker 上的其他请求。

适合由 Nginx 完成的工作通常短小且可预测；复杂业务逻辑应留在 Application Service。

请求处理路径

Nginx 先根据 Listen Address/Port 和 server_name 选择 Virtual Server，再匹配 location，最后由静态文件、Proxy、FastCGI、uWSGI、gRPC 等 Content Handler 产生响应。

Reload

nginx -s reload 向 Master 发送 Reload Signal。Master 验证新配置并尝试打开所需资源：

• 成功：启动新 Worker，旧 Worker 停止接收新连接并处理完在途请求后退出。
• 失败：保留旧配置与旧 Worker，不直接让当前服务中断。

Reload 前仍应先执行 nginx -t。配置语法正确不代表 Upstream、证书权限和业务路由一定正确，还需做 Smoke Test。