Nginx架构简述

女爷i 2022-04-03 07:56 188阅读 0赞

众所周知，Nginx 性能高，而 Nginx 的高性能与其架构是分不开的。那么 Nginx 究竟是怎么样的呢？

Nginx 在启动后，在 unix 系统中会以 ***守护进程*** 的方式在后台运行
    后台进程包含一个 master 进程和多个 worker 进程
    
    我们也可以手动地关掉后台模式，让 Nginx 在前台运行
    并且通过配置让 Nginx 取消 master 进程，从而可以使 Nginx 以单进程方式运行。
    
    很显然，生产环境下我们肯定不会这么做
    所以关闭后台模式，一般是用来调试用的

--------------------

Nginx 是以多进程的方式来工作的，当然 Nginx 也是支持多线程的方式的
    我们主流的方式还是多进程的方式，也是 Nginx 的默认方式。
    
    Nginx 在启动后，会有一个 master 进程和多个 worker 进程。
    
    master进程主要用来管理 worker进程，包含：
        1. 接收来自外界的信号
        2. 向各 worker 进程发送信号
        3. 监控 worker 进程的运行状态
        4. 当 worker 进程退出后(异常情况下)，会自动重新启动新的 worker进程。
        
    基本的网络事件是放在 worker 进程中来处理；
    多个 worker 进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的；
    一个请求，只可能在一个 worker 进程中处理，一个 worker 进程，不可能处理其它进程的请求；
    worker 进程的个数是可以设置的，一般我们会设置与机器cpu核数一致；

--------------------

> Nginx 操作

要操作 Nginx，只需要与 master 进程通信就行了。
    master 进程会接收来自外界发来的信号，再根据信号做不同的
    事情。
    所以我们要控制 Nginx，只需要通过 kill 向 master 进程发送信号就行了。比如 
    
    # kill -HUP pid 
    
    则是告诉Nginx，从容地重启 Nginx
    我们一般用这个信号来重启Nginx，或重新加载配置,因为是从容地重启，因此服务是不中断的。

**master 进程在接收到 HUP 信号后是怎么做的呢？**

首先 master 进程在接到信号后，会先重新加载配置文件
    然后再启动新的 worker 进程，并向所有老的 worker进程发送信号，告诉他们可以光荣退休了。
    新的 worker 在启动后，就开始接收新的请求
    而老的 worker 在收到来自 master 的信号后，就不再接收新的请求
    并且在当前进程中的所有未处理完的请求处理完成后，再退出。

**当然，直接给 master 进程发送信号，这是比较老的操作方式**

Nginx 在 0.8 版本之后，引入了一系列命令行参数，来方便我们管理。
    比如
    
    重启 Nginx
    ./nginx -s reload 
    
    停止 Nginx
    ./nginx -s stop

**如何做到的呢？**

我们还是拿reload 来说，我们看到，执行命令时，我们是启动一个新的 Nginx 进程
    而新的 Nginx 进程在解析到 reload参数后，就需要控制 Nginx 来重新加载配置文件
    它会向 master 进程发送信号，接下来的动作，就和我们直接向 master 进程发送信号一样了

--------------------

> worker 进程如何处理请求

我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。

**当我们提供 80 端口的 http服务时一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？**

首先，每个 worker 进程都是从 master 进程 fork 过来的
    
    在 master 进程里面，先建立好需要 listen 的 socket（listenfd）之后，然后再 fork 出多个 worker 进程。
    所有 worker 进程的 listenfd 会在新连接到来时变得可读。
    
    为保证只有一个进程处理该连接，所有 worker 进程在注册 listenfd 读事件前抢 accept_mutex。
    抢到互斥锁的那个进程注册 listenfd 读事件，在读事件里调用 accept 接受该连接。
    
    当一个 worker 进程在 accept 这个连接之后，
    就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接。
    
    这样一个完整的请求就是这样的了。
    我们可以看到，一个请求，完全由 worker 进程来处理，而且只在一个 worker 进程中处理。

--------------------

**Nginx 采用这种进程模型有什么好处呢？**

首先，对于每个 worker 进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销
    
    其次，独立的进程互相不会影响，一个进程退出后其它进程还在工作，master 进程则很快启动新的 worker 进程

--------------------

**Nginx 是如何处理事件的**

Nginx 采用多 worker 的方式来处理请求
    每个 worker 里面只有一个主线程，那能够处理的并发数很有限啊，多少个 worker 就能处理多少个并发，何来高并发呢？
    
    Nginx 采用了异步非阻塞的方式来处理请求

学习之余也不要忘了劳逸结合哦

喜欢天马行空的同学请关注公众号：  
![只为了博君一笑，没有别的用处][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjMxNzk3_size_16_color_FFFFFF_t_70]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI3NjMxNzk3_size_16_color_FFFFFF_t_70]: /images/20220403/d914bac5ffc644febeb2f237783996b3.png