【Django】初探Nginx架构

电玩女神 2022-06-03 09:55 200阅读 0赞

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

Nginx在启动后，在UNIX系统中会以daemon的方式在后台运行，后台进程包含一个master进程和多个worker进程。我们也可以手动地关掉后台模式，让nginx在前台运行，并且通过配置让nginx取消master进程，从而可以使nginx以单进程方式运行。很显然，生产环境下我们肯定不会这么做，所以关闭后台模式，一般是用来调试用的。所以，我们可以看到，Nginx是以多进程的方式来工作的，当然Nginx也是支持多线程的方式的，只是我们主流的方式还是多进程的方式，也是Nginx的默认方式。Nginx采用多进程的方式有诸多好处，所以我就主要讲解Nginx的多进程模式吧。

刚才讲到，Nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数是可以设置的，一般我们会设置与机器CPU核数一致，这里面的原因与Nginx的进程模型以及事件处理模型是分不开的。

## Nginx配置的基本方法 ##

首先分析一下nginx.conf原始配置文件来介绍配置的基本方法。

# 以下内容是全局块
    #user nobody;
    worker_processes  8;
    error_log  logs/error.log;
    error_log  logs/error.log notice;
    error_log  logs/error.log info;
    pid        logs/nginx.pid;
    
    # 以下内容是events块
    events {
        worker_connections  1024;
    }
    
    # 以下内容是http块
    http {
        # 以下内容是http全局块
        include       mime.types;
        default_type  application/octet-stream;
    
        sendfile        on;
        #tcp_nopush on;
        keepalive_timeout  65;
        #gzip on;
    
        # upstream的负载均衡，weight是权重，可以根据机器配置定义权重。weigth参数表示权值，权值越高被分配到的几率越大。
        upstream backend {
            #ip_hash;
            server 192.168.1.251 weight=3;
            server 192.168.1.252 weight=2;
            server 192.168.1.247 weight=3;
        }
    
        # 以下内容是server块
        server {
            # 以下内容是server全局块
            listen       80;
            server_name  2;
    
            location / {
            #设置主机头和客户端真实地址，以便服务器获取客户端真实IP
                 proxy_set_header Host $host;
                 proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    
                 #禁用缓存
                 proxy_buffering off;
    
                 #反向代理的地址
                 proxy_pass http://backend;     
            }
        }
    }
    
    mail {
        auth_http  127.0.0.1:80/auth.php;
        pop3_capabilities  "TOP"  "USER";
        imap_capabilities  "IMAP4rev1"  "UIDPLUS";
    
        server {
            listen     110;
            protocol   pop3;
            proxy      on;
        }
        server {
            listen      25;
            protocol    smtp;
            proxy       on;
            smtp_auth   login plain;
            xclient     off;
        }
    }

以上是原始nginx.conf配置文件的部分内容，从中可以看到配置的内容一共分成三大块，即全局块、events块和http块，其中http块中包含http全局块和server块，server块可以有多个并且在每个server块中又包含server全局块和location块。

### 1. 全局块 ###

worker_process 4;

每个worker进程都是单线程的进程，几个CPU内核就给几个worker进程。一个worker进程独享一个CPU，就在内核的调度策略上实现了完全的并发。

### 2. events块 ###

events块的设置对Nginx服务器的性能影响较大，主要设置一些影响Nginx服务器与用户网络连接的配置指令。events块的作用域是整个服务器，它的内容主要包括每个worker进程可以同时支持的最大连接数、选取哪种事件驱动模型来处理连接请求、是否允许同时接受多个网络连接以及是否开启对多个worker进程下的网络连接进行序列化等。

worker_connections 1024;

每个worker进程的最大连接数设置。

选择事件驱动模型设置；默认会自动选择最合适的事件模型。

multi_accept on|off;

批量建立新连接设置；当事件模型通知有新连接时，尽可能地对所有TCP请求都建立连接。

accept_mutex on|off;

网络连接序列化accept锁相关的设置；accept\_mutex是Nginx的负载均衡锁，当一个worker进程建立的连接数量达到worker——connections配置的最大连接数的7/8时，会大大减少worker进程试图建立新的TCP连接的机会。

### 3. http块 ###

http块是Nginx服务器配置的重要部分，主要设置代理、缓存和日志定义等大部分功能及第三方模块的配置等指令。http块包括http全局块和多个server块。其中http全局块是指不包含在server块中的部分，它的内容主要包括文件引入、MIME Type定义、日志格式及存放位置定义、是否开启sendfile传输文件、连接超时时间设置、单个连接的请求数上限等。

sendfile on;

开启高效文件传输模式。sendfile指令指定Nginx是否调用sendfile函数来输出文件，对于普通应用设为on，如果用来进行下载应用磁盘I/O重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常把这指令改成off。

tcp_nodelay on;

防止网络阻塞。

keepalive_timeout 65;

长连接超时时间，单位是秒。

### 4. server块 ###

一个server块相当于一台虚拟主机，虚拟主机配置的内容使得一台虚拟主机能够完成和一台独立的硬件主机一样的功能。server块包括server全局块和多个location块。其中server全局块的作用域是当前的server块，不会影响其他的server块，它的内容主要包括当前虚拟主机的监听端口设置和虚拟主机名称的IP配置。

listen 80;

监听端口。

server_name example.mytest.com;

虚拟主机的域名可以有多个，用空格隔开。

root html;

定义根目录。

### 5. location块 ###

location块在整个Nginx配置文档中的作用非常重要，主要作用是Nginx服务器接收到浏览器发来的请求字符串，然后对请求字符串中的URI部分进行匹配，从而对不同的请求进行不同的处理。而且，地址重定向、数据缓存和应答控制等功能都是在这部分实现，还有许多第三方模块的配置也是在这部分进行相关配置。

一般进行location匹配时会用包含正则表达式的字符串来进行location正则匹配，匹配可以有多个，但是当第一个正则匹配请求URI时就停止匹配，使用location块处理这个请求。

## Nginx的进程模型 ##

首先，对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查找时，也会方便很多。其次，采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，大家可以慢慢体会。

## Nginx的事件处理模型 ##

有人可能要问了，nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。想想apache的常用工作方式（apache也有异步非阻塞版本，但因其与自带某些模块冲突，所以不常用），每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。

为什么nginx可以采用异步非阻塞的方式来处理呢，或者异步非阻塞到底是怎么回事呢？我们先回到原点，看看一个请求的完整过程。首先，请求过来，要建立连接，然后再接收数据，接收数据后，再发送数据。具体到系统底层，就是读写事件，而当读写事件没有准备好时，必然不可操作，如果不用非阻塞的方式来调用，那就得阻塞调用了，事件没有准备好，那就只能等了，等事件准备好了，你再继续吧。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。好吧，你说加进程数，这跟apache的线程模型有什么区别，注意，别增加无谓的上下文切换。所以，在nginx里面，最忌讳阻塞的系统调用了。不要阻塞，那就非阻塞喽。非阻塞就是，事件没有准备好，马上返回EAGAIN，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的。所以，才会有了异步非阻塞的事件处理机制，具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。它们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制正好解决了我们上面的两个问题，拿epoll为例(在后面的例子中，我们多以epoll为例子，以代表这一类函数)，当事件没准备好时，放到epoll里面，事件准备好了，我们就去读写，当读写返回EAGAIN时，我们将它再次加入到epoll里面。这样，只要有事件准备好了，我们就去处理它，只有当所有事件都没准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。更多的并发数，只是会占用更多的内存而已。 我之前有对连接数进行过测试，在24G内存的机器上，处理的并发请求数达到过200万。现在的网络服务器基本都采用这种方式，这也是nginx性能高效的主要原因。

我们之前说过，推荐设置worker的个数为cpu的核数，在这里就很容易理解了，更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，提供了cpu亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效。像这种小的优化在nginx中非常常见，同时也说明了nginx作者的苦心孤诣。比如，nginx在做4个字节的字符串比较时，会将4个字符转换成一个int型，再作比较，以减少cpu的指令数等等。

## Nginx的模块化体系结构 ##

nginx提供了web服务器的基础功能，同时提供了web服务反向代理，email服务反向代理功能。nginx core实现了底层的通讯协议，为其他模块和nginx进程构建了基本的运行时环境，并且构建了其他各模块的协作基础。除此之外，或者说大部分与协议相关的，或者应用相关的功能都是在这些模块中所实现的。

## Nginx的模块分类 ##

<table> 
 <thead> 
  <tr> 
   <th>模块</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>event module</td> 
   <td>搭建了独立于操作系统的事件处理机制的框架，及提供了各具体事件的处理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具体使用何种事件处理模块，这依赖于具体的操作系统和编译选项。</td> 
  </tr> 
  <tr> 
   <td>phase handler</td> 
   <td>此类型的模块也被直接称为handler模块。主要负责处理客户端请求并产生待响应内容，比如ngx_http_static_module模块，负责客户端的静态页面请求处理并将对应的磁盘文件准备为响应内容输出。</td> 
  </tr> 
  <tr> 
   <td>output filter</td> 
   <td>也称为filter模块，主要是负责对输出的内容进行处理，可以对输出进行修改。例如，可以实现对输出的所有html页面增加预定义的footbar一类的工作，或者对输出的图片的URL进行替换之类的工作。</td> 
  </tr> 
  <tr> 
   <td>upstream</td> 
   <td>upstream模块实现反向代理的功能，将真正的请求转发到后端服务器上，并从后端服务器上读取响应，发回客户端。upstream模块是一种特殊的handler，只不过响应内容不是真正由自己产生的，而是从后端服务器上读取的。</td> 
  </tr> 
  <tr> 
   <td>load-balancer</td> 
   <td>负载均衡模块，实现特定的算法，在众多的后端服务器中，选择一个服务器出来作为某个请求的转发服务器。</td> 
  </tr> 
 </tbody> 
</table>