Nginx的使用

什么是Nginx

Nginx—-Ngine X，是一款免费的、自由的、开源的、高性能HTTP服务器和反向代理服务器；也是一个IMAP、POP3、SMTP代理服务器；Nginx以其高性能、稳定性、丰富的功能、简单的配置和低资源消耗而闻名。

也就是说Nginx本身就可以托管网站（类似于Tomcat一样），进行Http服务处理，也可以作为反向代理服务器 、负载均衡器和HTTP缓存。

Nginx 解决了服务器的C10K（就是在一秒之内连接客户端的数目为10k即1万）问题。它的设计不像传统的服务器那样使用线程处理请求，而是一个更加高级的机制—事件驱动机制，是一种异步事件驱动结构。

2、请列举Nginx的一些特性

跨平台：可以在大多数Unix like 系统编译运行。而且也有Windows的移植版本。

配置异常简单：非常的简单，易上手。

非阻塞、高并发连接：数据复制时，磁盘I/O的第一阶段是非阻塞的。官方测试能支持5万并发连接，实际生产中能跑2~3万并发连接数（得益于Nginx采用了最新的epoll事件处理模型（消息队列）。

Nginx代理和后端Web服务器间无需长连接；

Nginx接收用户请求是异步的，即先将用户请求全部接收下来，再一次性发送到后端Web服务器，极大减轻后端Web服务器的压力。

发送响应报文时，是边接收来自后端Web服务器的数据，边发送给客户端。

网络依赖性低，理论上只要能够ping通就可以实施负载均衡，而且可以有效区分内网、外网流量。

支持内置服务器检测。Nginx能够根据应用服务器处理页面返回的状态码、超时信息等检测服务器是否出现故障，并及时返回错误的请求重新提交到其它节点上。

此外还有内存消耗小、成本低廉（比F5硬件负载均衡器廉价太多）、节省带宽、稳定性高等特点。

3、请列举Nginx和Apache 之间的不同点

 

请解释Nginx如何处理HTTP请求。

Nginx 是一个高性能的 Web 服务器，能够同时处理大量的并发请求。它结合多进程机制和异步机制 ，异步机制使用的是异步非阻塞方式 ，接下来就给大家介绍一下 Nginx 的多线程机制和异步非阻塞机制 。

1、多进程机制

服务器每当收到一个客户端时，就有 服务器主进程 （ master process ）生成一个 子进程（ worker process ）出来和客户端建立连接进行交互，直到连接断开，该子进程就结束了。

使用进程的好处是各个进程之间相互独立，不需要加锁，减少了使用锁对性能造成影响，同时降低编程的复杂度，降低开发成本。其次，采用独立的进程，可以让进程互相之间不会影响 ，如果一个进程发生异常退出时，其它进程正常工作， master 进程则很快启动新的 worker 进程，确保服务不会中断，从而将风险降到最低。

缺点是操作系统生成一个子进程需要进行 内存复制等操作，在资源和时间上会产生一定的开销。当有大量请求时，会导致系统性能下降 。

2、异步非阻塞机制

每个工作进程 使用 异步非阻塞方式 ，可以处理 多个客户端请求 。

当某个 工作进程 接收到客户端的请求以后，调用 IO 进行处理，如果不能立即得到结果，就去 处理其他请求 （即为 非阻塞 ）；而 客户端 在此期间也 无需等待响应 ，可以去处理其他事情（即为 异步 ）。

当 IO 返回时，就会通知此 工作进程 ；该进程得到通知，暂时 挂起 当前处理的事务去 响应客户端请求 。

6、 使用“反向代理服务器”的优点是什么?

反向代理服务器可以隐藏源服务器的存在和特征。它充当互联网云和web服务器之间的中间层。这对于安全方面来说是很好的，特别是当您使用web托管服务时。

9、请解释代理设计中的正向代理和反向代理?

首先，代理服务器一般指局域网内部的机器通过代理服务器发送请求到互联网上的服务器，代理服务器一般作用在客户端。例如：GoAgentFQ软件。我们的客户端在进行FQ操作的时候，我们使用的正是正向代理，通过正向代理的方式，在我们的客户端运行一个软件，将我们的HTTP请求转发到其他不同的服务器端，实现请求的分发。

反向代理服务器作用在服务器端，它在服务器端接收客户端的请求，然后将请求分发给具体的服务器进行处理，然后再将服务器的相应结果反馈给客户端。Nginx就是一个反向代理服务器软件。

从上图可以看出：客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的IP地址，还有代理程序的端口。
反向代理正好与正向代理相反，对于客户端而言代理服务器就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间（name-space）中的内容发送普通请求，接着反向代理将判断向何处（原始服务器）转交请求，并将获得的内容返回给客户端。

10、请解释是否有可能将Nginx的错误替换为502错误、503?

502 =错误网关

503 =服务器超载

4、Nginx是如何处理一个请求的呢？
首先，nginx在启动时，会解析配置文件，得到需要监听的端口与ip地址，然后在nginx的master进程里面
先初始化好这个监控的socket，再进行listen
然后再fork出多个子进程出来, 子进程会竞争accept新的连接。
此时，客户端就可以向nginx发起连接了。当客户端与nginx进行三次握手，与nginx建立好一个连接后，此时，某一个子进程会accept成功，然后创建nginx对连接的封装，即ngx_connection_t结构体接着，根据事件调用相应的事件处理模块，如http模块与客户端进行数据的交换，最后，nginx或客户端来主动关掉连接，到此，一个连接就寿终正寝了
五、动态资源、静态资源分离的原因
动态资源、静态资源分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路
动态资源、静态资源分离简单的概括是：动态文件与静态文件的分离
二者分离的原因
在我们的软件开发中，有些请求是需要后台处理的（如：.jsp,.do等等），有些请求是不需要经过后台处理的（如：css、html、jpg、js等等文件）
这些不需要经过后台处理的文件称为静态文件，否则动态文件。因此我们后台处理忽略静态文件。这会有人又说那我后台忽略静态文件不就完了吗
当然这是可以的，但是这样后台的请求次数就明显增多了。在我们对资源的响应速度有要求的时候，我们应该使用这种动静分离的策略去解决
动、静分离将网站静态资源（HTML，JavaScript，CSS，img等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问
这里我们将静态资源放到nginx中，动态资源转发到tomcat服务器中

 

 

现在假设有三台主机，他们的ip分别为：

A: 192.168.1.167

B: 192.168.1.168

nginx作为代理服务器部署在主机 A 上面，B 和 C 作为两台应用服务器。现在想实现通过A访问B和C，有以下两种方式：

一、通过不同的listen实现对B和C的访问，实现方式如下：在nginx.conf中添加两个server

server {
            listen  8081;
            server_name test1;
            location / {
                proxy_pass http://192.168.1.168：9093;
            }
   }

 

注意：1、在以上配置中，server_name可以任意取名

           2、主机B的访问方式通过A监听端口8081来代理，访问A的8081端口：http://192.168.1.167:8081

　　　3、nginx再通过proxy_pass的地址访问对应的服务器

二、通过相同的listen，不同的server_name实现对B和C的访问，即通过不同的域名方式访问B和C，实现方式如下：

server {
            listen  8080;
            server_name www.test1.com;
            location / {
                proxy_pass http://192.168.1.168:9093;
            }
   }

 

注意：1、在以上配置中，server_name表示B和C的域名

           2、主机B和C的访问方式都通过A监听端口8080来代理

           3、由于是测试，需要在测试端修改hosts文件，即在hosts文件中添加以下内容

                192.168.1.168 www.test1.co

           4、访问方式：在修改了hosts文件的电脑上按以下方式分别访问B和C：

                http://www.test1.com:8080

             

              其中：

                 linux下hosts所在路径：/etc/hosts

                 windows下hosts所在路径：C:\Windows\System32\drivers\etc\hosts

           server name 为虚拟服务器的识别路径。因此对于相同的listen不同的域名会通过请求头中的HOST字段，匹配到特定的server块，转发到对应的应用服务器中去。

　　　基于域名的虚拟主机(name based virtual host)，配置的方法就是多个虚拟主机绑定同一个端口，通过server_name区分。

　　基于的理论基础就是http协议中会带一个HOST头，web server通过这个头判断具体交给哪个虚拟主机响应。如果没有一个匹配，那么通常哪个在前哪个优先响应，这个叫默认虚拟主机,apache有个_default_属性可以强行指定某一个虚拟主机为默认虚拟主机。如下图

 hosts文件指定IP与域名的对应关系（如：192.168.1.169 www.test2.com），对域名的访问会映射成对应的IP。这个ip就是nginx的公网IP 。然后server name 为虚拟服务器的识别路径。因此不同的域名会转发到对应的应用服务器中去。

对upstream 的配置实现负载均

upstream linuxidc { 
      server 10.0.6.108:7080; 
      server 10.0.0.85:8980; 
}

2.  将server节点下的location节点中的proxy_pass配置为：http:// + upstream名称，即“
http://linuxidc”

location / { 
            root  html; 
            index  index.html index.htm; 
            proxy_pass http://linuxidc; 
}

    3.  如今负载均衡初步完毕了。upstream依照轮询（默认）方式进行负载，每一个请求按时间顺序逐一分配到不同的后端服务器。假设后端服务器down掉。能自己主动剔除。尽管这样的方式简便、成本低廉。但缺点是：可靠性低和负载分配不均衡。

 适用于图片服务器集群和纯静态页面服务器集群。

 

以下还介绍四种均和策略：

weight（权重）

    指定轮询几率，weight和訪问比率成正比，用于后端服务器性能不均的情况。例如以下所看到的。10.0.0.88的訪问比率要比10.0.0.77的訪问比率高一倍。

upstream linuxidc{ 
      server 10.0.0.77 weight=5; 
      server 10.0.0.88 weight=10; 
}

 ip_hash（訪问ip）

    每一个请求按訪问ip的hash结果分配。这样每一个訪客固定訪问一个后端服务器，能够解决session的问题。

upstream favresin{ 
      ip_hash; 
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
}

fair（第三方）

    按后端服务器的响应时间来分配请求。响应时间短的优先分配。

与weight分配策略相似。

 upstream favresin{      
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
      fair; 
}

url_hash（第三方）

按訪问url的hash结果来分配请求，使每一个url定向到同一个后端服务器。后端服务器为缓存时比較有效。

 

注意：在upstream中加入hash语句。server语句中不能写入weight等其他的參数，hash_method是使用的hash算法。

 upstream resinserver{ 
      server 10.0.0.10:7777; 
      server 10.0.0.11:8888; 
      hash $request_uri; 
      hash_method crc32; 
}

upstream还能够为每一个设备设置状态值，这些状态值的含义分别例如以下：

down 表示单前的server临时不參与负载.

weight 默觉得1.weight越大，负载的权重就越大。

max_fails ：同意请求失败的次数默觉得1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.

fail_timeout : max_fails次失败后。暂停的时间。

backup： 其他全部的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

upstream bakend{ #定义负载均衡设备的Ip及设备状态 
      ip_hash; 
      server 10.0.0.11:9090 down; 
      server 10.0.0.11:8080 weight=2; 
      server 10.0.0.11:6060; 
      server 10.0.0.11:7070 backup; 
}

 

主机下线 

说明:当Nginx反向代理时,如果tomcat发生宕机那么用户的请求依然会发往故障机.导致请求超时.用户得不到响应结果.

方案:使用down实现下线处理

在配置文件中对故障机进行down标记.重启nginx后将不会再把请求发往故障机.

upstream jt {

server localhost:8091 weight=6;

server localhost:8092 weight=3 down;

server localhost:8093 weight=1;

}

Nginx健康检测

说明:当后台的服务器出现宕机的现象,当时nginx中的配置文件并没有改变时,请求依然会发往故障的机器.需要人为的维护配置文件,这样的操作不智能.那么采用健康检测机制.可以实现故障的自动的迁移.

属性介绍:

1.max_fails=1  当检测服务器是否正常时,如果检测失败的次数达到规定的次数时,则断定该服务器故障,在规定的时间周期内,不会将请求发往该机器.

2.fail_timeout=60s定义时钟周期

设定健康检测

upstream jt {

server localhost:8091 weight=6 max_fails=1 fail_timeout=60s;

server localhost:8092 weight=3 max_fails=1 fail_timeout=60s;

server localhost:8093 weight=1 max_fails=1 fail_timeout=60s;

}

2.定义超时时间.

#配置后台管理服务器

server {

listen 80;

server_name manage.jt.com;

 

location / {

#反向代理到url中

#proxy_pass http://localhost:8091;

proxy_pass  http://jt;

proxy_connect_timeout       1;  

        proxy_read_timeout          1;  

        proxy_send_timeout          1;

}

}

}

说明:当Nginx反向代理时,如果tomcat发生宕机那么用户的请求依然会发往故障机.导致请求超时.用户得不到响应结果.

方案:使用down实现下线处理

在配置文件中对故障机进行down标记.重启nginx后将不会再把请求发往故障机.

upstream jt {

server localhost:8091 weight=6;

server localhost:8092 weight=3 down;

server localhost:8093 weight=1;

}

nginx常用命令

sudo nginx #打开 nginx
nginx -s reload|reopen|stop|quit #重新加载配置|重启|停止|退出 nginx
nginx -t #测试配置是否有语法错误

nginx [-?hvVtq] [-s signal] [-c filename] [-p prefix] [-g directives]

-?,-h : 打开帮助信息
-v : 显示版本信息并退出
-V : 显示版本和配置选项信息，然后退出
-t : 检测配置文件是否有语法错误，然后退出
-q : 在检测配置文件期间屏蔽非错误信息
-s signal : 给一个 nginx 主进程发送信号：stop（停止）, quit（退出）, reopen（重启）, reload（重新加载配置文件）
-p prefix : 设置前缀路径（默认是：/usr/local/Cellar/nginx/1.2.6/）
-c filename : 设置配置文件（默认是：/usr/local/etc/nginx/nginx.conf）
-g directives : 设置配置文件外的全局指令