Nginx详细介绍

最新推荐文章于 2024-09-05 13:59:20 发布

百里度

最新推荐文章于 2024-09-05 13:59:20 发布

阅读量2.4k

点赞数 3

分类专栏： Nginx 文章标签： nginx

本文链接：https://blog.csdn.net/qq_20161461/article/details/107779759

版权

Nginx 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、nginx 主要应用场景
1、反向代理
反向代理应该是Nginx做的最多的一件事了，什么是反向代理呢，以下是百度百科的说法：反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。
在这里插入图片描述

关键命令：proxy_pass；如将 localhost 的80端口 转到 localhost 8080端口

server { 
　　 listen 80; 
    server_name localhost; 

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host:$server_port;
　　}
}

2、负载均衡
负载均衡也是Nginx常用的一个功能，简单而言就是当有2台或2台以上服务器时，根据规则随机的将请求分发到指定的服务器上处理，负载均衡配置一般都需要同时配置反向代理，通过反向代理跳转到负载均衡。而Nginx目前支持自带3种负载均衡策略，还有2种常用的第三方策略

关键命令：upstream；如将localhost 80端口的请求均分到 localhost 8080 和 localhost 8081两个服务上

负载方案：

1）、权重 weight：必须实现session 共享，否则导致用户session不同步，导致用户重新登陆

upstream test {
        server localhost:8080 weight=9;  #请求的 90% 进入到8080服务器
        server localhost:8081 weight=1;  #请求的 10% 进入到8081服务器
    }

2）、ip_hash：每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题

upstream test {
        ip_hash;
        server localhost:8080;
        server localhost:8081;
    }

3）、fair(第三方)：按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream test {
        fair;
        server localhost:8080;
        server localhost:8081;
}

4）、url_hash(第三方)：问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效

upstream backend {
        hash $request_uri;
        hash_method crc32;
        server localhost:8080;
        server localhost:8081;
    }

5)、默认：按照时间一次分配到不同的机器上

upstream test {
        server localhost:8080;
        server localhost:8081;
    }
    server {
        listen       80;                                                        
        server_name  localhost;                                              
        client_max_body_size 1024M;

        location / {
            proxy_pass http://test;
            proxy_set_header Host $host:$server_port;
        }
    }

3、WEB服务器
Nginx本身也是一个静态资源的服务器，当只有静态资源的时候，就可以使用Nginx来做服务器，同时现在也很流行动静分离，就可以通过Nginx来实现，首先看看Nginx做静态资源服务器

这样如果访问 http://localhost 就会默认访问到 E://www/data目录下面的index.html，如果一个网站只是静态页面的话，那么就可以通过这种方式来实现部署

关键命令：root 当只有静态资源的时候，就可以使用Nginx来做服务器

server {
        listen       80;                                                        
        server_name  localhost;                                              

        location / {
               root   e:/www/data;
               index  index.html;
           }
    }

4、静态分离
动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。

upstream test{ 
       server localhost:8080; 
       server localhost:8081; 
    } 
 
    server { 
        listen       80; 
        server_name  localhost; 
 
        location / { 
            root   e:/wwwroot; 
            index  index.html; 
        } 
 
        # 所有静态请求都由nginx处理，存放目录为html 
        location ~ .(gif|jpg|jpeg|png|bmp|swf|css|js)$ { 
            root    e:/wwwroot; 
        } 
 
        # 所有动态请求都转发给tomcat处理 
        location ~ .(do)$ { 
            proxy_pass  http://test; 
        } 
 
        error_page   500 502 503 504  /50x.html; 
        location = /50x.html { 
            root   e:/wwwroot; 
        } 
    }

二、Nginx的特点
（1）跨平台：Nginx 可以在大多数 Unix like OS编译运行，而且也有Windows的移植版本。
（2）配置异常简单，非常容易上手。配置风格跟程序开发一样，神一般的配置
（3）非阻塞、高并发连接：数据复制时，磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数.(这得益于Nginx使用了最新的epoll模型)
（4）事件驱动：通信机制采用epoll模型，支持更大的并发连接。
（5）master/worker结构：一个master进程，生成一个或多个worker进程
（6）内存消耗小：处理大并发的请求内存消耗非常小。在3万并发连接下，开启的10个Nginx 进程才消耗150M内存（15M*10=150M）
（7）成本低廉：Nginx为开源软件，可以免费使用。而购买F5 BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币
（8）内置的健康检查功能：如果 Nginx Proxy 后端的某台 Web 服务器宕机了，不会影响前端访问。
（9）节省带宽：支持 GZIP 压缩，可以添加浏览器本地缓存的 Header 头。
（10）稳定性高：用于反向代理，宕机的概率微乎其微

三、Nginx的事件处理机制：
对于一个基本的web服务器来说，事件通常有三种类型，网络事件、信号、定时器。
首先看一个请求的基本过程：建立连接—接收数据—发送数据。
再次看系统底层的操作：上述过程（建立连接—接收数据—发送数据）在系统底层就是读写事件。

1）如果采用阻塞调用的方式，当读写事件没有准备好时，必然不能够进行读写事件，那么久只好等待，等事件准备好了，才能进行读写事件。那么请求就会被耽搁。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了。

2）既然没有准备好阻塞调用不行，那么采用非阻塞方式。非阻塞就是，事件，马上返回EAGAIN，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的

小结：非阻塞通过不断检查事件的状态来判断是否进行读写操作，这样带来的开销很大。

3）因此才有了异步非阻塞的事件处理机制。具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。他们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制解决了我们上面两个问题。

以epoll为例：当事件没有准备好时，就放入epoll(队列)里面。如果有事件准备好了，那么就去处理；如果事件返回的是EAGAIN，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理她，只有当所有时间都没有准备好时，才在epoll里面等着。这样，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理解为循环处理多个准备好的事件，事实上就是这样的。

4）与多线程的比较：
与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。

小结：通过异步非阻塞的事件处理机制，Nginx实现由进程循环处理多个准备好的事件，从而实现高并发和轻量级。

四、Nginx的内部(进程)模型
在这里插入图片描述

nginx是以多进程的方式来工作的。
nginx在启动后，会有一个master进程和多个worker进程
master进程主要用来管理worker进程：
包含：
1、接收来自外界的信号，向各worker进程发送信号。
2、监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。worker进程之间是对等的，一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数，一般会设置与机器cpu核数一致。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接。

nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的