17《Nginx 入门教程》Nginx 的基础架构解析(上)

Posted 2023-03-23

参考技术A 前面介绍 nginx 时有介绍过 Nginx 的进程模型。Nginx 启动时首先启动一个 Master 进程，然后由 Master 进程启动一个或者多个 Worker 子进程。Master 进程主要完成配置读取，通过发送信号控制 Worker 进程的启动和停止等，而 Worker 子进程是用来处理客户端发来的 Http 请求，且Worker进程之间会通过共享内存进行通信。

假设 Nginx 启动了多个 Worker 进程，并且在 Master 进程中通过 socket 套接字监听80端口。 这些 Worker 进程 fork 自 Master 进程，然后每个worker进程都可以去 accept 这个监听的 socket。 当一个连接进来后，所有在 accept 在这个 socket 上面的进程，都会收到消息，但是只有一个进程可以 accept 这个连接，其它的则 accept 失败，这便是所谓的惊群现象。Nginx 处理这种情况的方式就是加锁。有了锁之后，在同一时刻，就只会有一个 Worker 进程在 accpet 连接，这样就不会有惊群问题了。在 Worker 进程拿到 Http 请求后，就开始按照前面介绍的 11个阶段处理该 Http 请求，最后返回响应结果并断开连接。

最早我们学习了 Nginx 命令行操作，这些命令行操作都是给 Master 进程发信号，然后再由 Master 进程发送信号给 Worker 进程，从而达到控制 Worker 进程的目标。我们以 Nginx 的热部署命令 ./nginx -s reload 来描述 Nginx 命令行的执行流程。具体过程如下:

Nginx 命令行中 -s 参数的每个值都对应这一个信号。因此，我们也可以直接对 Master 进程发生相应信号达到同样的目的。

事件驱动模型是实现异步非阻塞的一个手段。对于 web 服务器来说，客户端 A 的请求连接到服务端时，服务端的某个进程（Nginx 的 worker 进程）会处理该请求，此进程在没有返回给客户端 A 结果时，它又去处理了客户端 B 的请求。服务端把客户端 A 以及客户端 B 发来的请求作为事件交给了"事件收集器"，而"事件收集器"再把收集到的事件交由"事件发送器"发送给"事件处理器"进行处理。最后"事件处理器"处理完该事件后，通知服务端进程，服务端进程再把结果返回给客户端A、客户端B。在这个过程中，服务端进程做的事情属于用户级别的，而事件处理这部分工作属于内核级别的。也就是说这个事件驱动模型是需要操作系统内核来作为支撑的。

Nginx 的事件驱动模型，支持 select、poll、epoll、rtsig、kqueue、/dev/poll、eventport 等。 最常用的是前三种，特别是 epoll 模型，这也是 Nginx 中的默认配置。可以说 epoll 模型成就了 Nginx 的高性能和高并发特性。

按照前面的讲解，我们测试给 Nginx 的 Master 进程直接发送信号，并观察进程情况:

可以看到 Nginx 启动了 Master 进程(pid=10640)，后由 Master 进程 fork 除了两个 Worker 进程和两个 Cache 进程，他们的父进程 id 均为10640。现在做如下几个操作:

可以看到原先的 Worker 进程被杀死后，Nginx 的主进程又立马拉起来一个新的 Worker 进程提供服务。这说明 Nginx 是非常可靠的，只要 Master 进程还在就会保证 Worker 进程持续存在并提供服务。

可以看到，在移除 Nginx 的 access.log 日志后，在向 Nginx 主进程发送 USR1 信号，Nginx 会重新生成一个新的 access.log 日志。

本节主要介绍 Nginx 的进程模型以及介绍了 Master 和 Worker 之间的通信过程。此外，我们介绍了 Nginx 的事件驱动模型。异步、多路IO复用、非阻塞等特点早就了 Nginx 的高性能。接下来，我们完成了 Nginx 进程模型的几个实验，直观体检 Nginx 的进程模型。下一节将重点介绍 Nginx 模块相关的内容，并手动实现一个简单的 http 模块。