nginx反向代理 nginx.conf配制

Posted 2020-10-13

Nginx是什么？

由俄罗斯开发的反向代理服务器。nginx 是Web服务器或反向代理服务器。

优点：

 

• 跨平台：Nginx 可以在大多数 Unix like OS编译运行，而且也有Windows的移植版本。
• 配置异常简单：非常容易上手。配置风格跟程序开发一样，神一般的配置
• 非阻塞、高并发连接：数据复制时，磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数.(这得益于Nginx使用了最新的epoll模型)
• 事件驱动：通信机制采用epoll模型，支持更大的并发连接。

 

特点：

• nginx代理和后端web服务器间无需长连接；
• 接收用户请求是异步的，即先将用户请求全部接收下来，再一次性发送后后端web服务器，极大的减轻后端web服务器的压力
• 发送响应报文时，是边接收来自后端web服务器的数据，边发送给客户端的
• 网络依赖型低。NGINX对网络的依赖程度非常低，理论上讲，只要能够ping通就可以实施负载均衡，而且可以有效区分内网和外网流量

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

通过一个实例了解nginx

假设有三台服务器，一台是nginx服务器，两台是tomcat服务器（至少两台）

服务器	地址	用途
Nginx	192.168.129.10	反向代理
Tomcat1	192.168.129.11	运行tomcat
Tomcat1	192.168.129.12	运行tomcat

当浏览器发送请求时，是通过nginx来访问tomcat，获得数据后再由nginx传给浏览器显示。浏览器只能获得数据，不能知道是哪一个tomcat把数据传给他的，当然浏览器更是不想知道这些数据的，这样保护了tomcat服务器上的资源安全，这就是反向代理

下图是实际用户通过nginx访问数据，原始资源服务器被防火墙和nginx同时保护：

  

用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答，从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。

实例步骤：

在linux环境下，在两个tomcat1和tomcat2服务器下，启动tomcat

-1.上传tomcat的压缩包，解压到指定目录

  tar zxvf apache-tomcat-7.0.68.tar.gz

-2.到解压目录找到批处理文件，开启tomcat

  cd apache-tomcat-7.0.68

 ./bin/startup.sh

-3.可以查看一下日志文件，看是否成功

 tailf ./logs/catalina.out

修改nginx.conf

 vi /usr/local/nginx/conf/nginx.conf

 

在http节点下添加upstream（服务器集群），server设置的是集群服务器的信息，我这里搭建了两个站点，配置了两条信息。

    #新加服务器集群名称为Jq_one
    upstream localhost_jp{
 　　server  192.168.129.11:8080; 
 　　server  192.168.129.12:8080;
    }

 

    #在http节点下找到location节点修改

 

   location / {
            root  /home/ftpuser/www;
            index  index.html index.htm;

     #设置主机头和客户端真实地址，以便服务器获取客户端真实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_connect_timeout 10;

     #发送超时时间
     proxy_send_timeout 10;

     #接收超时时间
     proxy_read_timeout 10;

     #反向代理配置
     proxy_pass http://localhost_jp;
 }

 

保存之后，你就可以试一下访问192.168.129.10，返回的页面有可能是tomcat1，有可能是tomcat2中的数据

关于nginx选哪一个tomcat服务器，是有五种负载均衡策略的，下面介绍一下：

-1.轮循
默认采用此策略，根据访问的先后的时间，循环的访问代理服务。

-2.Ip_hash
同一ip，始终访问同一代理的服务。

upstream localhost_jp{

　　　ip_hash;
 　　server  192.168.129.11:8080; 
 　　server  192.168.129.12:8080;
   }
 
-3.权重
根据设置权重的值，自动计算百分比。

upstream localhost_jp{
 　　server  192.168.129.11:8080 weight=800; 
 　　server  192.168.129.12:8080 weight=200;
   }
 
-4.Fair
根据每个地址响应的时间，分配资源。时间越短，越优先访问。

-5.Url_hash
更具url地址计算hash值，同一url始终从同一服务器获取内容，常用于cdn。

Nginx的内部(进程)模型

nginx是以多进程的方式来工作的，当然nginx也是支持多线程的方式的,只是我们主流的方式还是多进程的方式，也是nginx的默认方式。nginx采用多进程的方式有诸多好处 .

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

(2)Master接收到信号以后怎样进行处理（./nginx -s reload ）?首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出 .

(3) worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master进程fork过来，在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。当然，nginx也不会视而不见，所以nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。

(4):，nginx采用这种进程模型有什么好处呢？采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，大家可以慢慢体会。

(5).有人可能要问了，nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的 .对于IIS服务器每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。我们之前说过，推荐设置worker的个数为cpu的核数，在这里就很容易理解了，更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，提供了cpu亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效

 

Nginx常见配置说明

worker_processes 8;

#nginx进程数，建议设置为等于CPU总核心数

worker_connections 65535;

#单个进程最大连接数（最大连接数=连接数*进程数）

client_header_buffer_size 32k; #上传文件大小限制

large_client_header_buffers 4 64k; #设定请求缓

client_max_body_size 8m; #设定请求缓

autoindex on; #开启目录列表访问，合适下载服务器，默认关闭。

tcp_nopush on; #防止网络阻塞

tcp_nodelay on; #防止网络阻塞

keepalive_timeout 120; #长连接超时时间，单位是秒

gzip on; #开启gzip压缩输出

gzip_min_length 1k; #最小压缩文件大小

gzip_buffers 4 16k; #压缩缓冲区

gzip_http_version 1.0; #压缩版本（默认1.1，前端如果是squid2.5请使用1.0）

gzip_comp_level 2; #压缩等级

upstream blog.ha97.com {

#upstream的负载均衡，weight是权重，可以根据机器配置定义权重。weigth参数表示权值，权值越高被分配到的几率越大。

server 192.168.80.121:80 weight=3;

server 192.168.80.122:80 weight=2;

server 192.168.80.123:80 weight=3;

}

#虚拟主机的配置

server

{

#监听端口

listen 80;

#域名可以有多个，用空格隔开

server_name www.ha97.com ha97.com;

index index.html index.htm index.php;

root /data/www/ha97;

location ~ .*.(php|php5)?$

{

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi.conf;

}