Nginx的正反向代理和配置文件详解

亮点：nginx负载均衡

亮点描述：

简述：

Nginx ("engine x") 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器。并在一个BSD-like 协议下发行，其特点是占有内存少，

并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

负载均衡的简述：

　  多台服务器处于一个内网，而我们要访问这些服务器，中间加一台 反向代理，根据各台服务器的负载，指定访问其中一台。这就叫负载均衡。

　　代理服务器来接受外部的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给外部的请求连接的客户端，此时代理

    服务器对外就表现为一个服务器。

作用：大型网站在接受用户请求的时候，这个访问量是巨大的，这个时候他就要设计怎么去分担这些请求压力。按照我们的理解就是搭建一个应用服务器的集群（tomcat）

每个用户请求进来都会按照不同的分发方式去访问相对应的服务器，这个时候负载均衡的实现就达到了。

反向代理和正向代理的区别：

正向代理：

正向代理,代理,他的工作原理就像一个跳板,

简单的说,

我是一个用户,我访问不了某网站,但是我能访问一个代理服务器

这个代理服务器呢,他能访问那个我不能访问的网站

于是我先连上代理服务器,告诉他我需要那个无法访问网站的内容

代理服务器去取回来,然后返回给我，这个时候我们用户取回的东西还是直接的最终服务端口。

反向代理:

（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet

上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

继续举例:

例用户访问 http://ooxx.me/readme
但ooxx.me上并不存在readme页面

他是偷偷从另外一台服务器上取回来,然后作为自己的内容吐给用户

但用户并不知情

这很正常,用户一般都很笨

这里所提到的 ooxx.me 这个域名对应的服务器就设置了反向代理功能

结论就是 反向代理正好相反，对于客户端而言它就像是原始服务器，并

且客户端不需要进行任何特别的设置。客户端向反向代理 的命名空间(name-space)

中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，

并将获得的内容返回给客户端，就像这些内容 原本就是它自己的一样。这个时候的

用户请求不知道访问的是哪里，用户其实是很笨的，在这里只是发送了请求而已。

配置项：

1、轮询         

        轮询是upstream的默认分配方式，即每个请求按照时间顺序轮流分配到不同的后端服务器，如果某个后端服务器down掉后，能自动剔除。

        upstream backend {

            server 192.168.1.101:8888;

            server 192.168.1.102:8888;

            server 192.168.1.103:8888;

        }

2、weight        

        轮询的加强版，即可以指定轮询比率，weight和访问几率成正比，主要应用于后端服务器异质的场景下。

        upstream backend {

            server 192.168.1.101 weight=1;

            server 192.168.1.102 weight=2;

            server 192.168.1.103 weight=3;

        }

3、ip_hash        

        每个请求按照访问ip（即Nginx的前置服务器或者客户端IP）的hash结果分配，这样每个访客会固定访问一个后端服务器，可以解决session一致问题。

        upstream backend {

             ip_hash;

            server 192.168.1.101:7777;

            server 192.168.1.102:8888;

            server 192.168.1.103:9999;

        }

4、fair        

        fair顾名思义，公平地按照后端服务器的响应时间（rt）来分配请求，响应时间短即rt小的后端服务器优先分配请求。

        upstream backend {

            server 192.168.1.101;

            server 192.168.1.102;

            server 192.168.1.103;

             fair;

        }

5、url_hash

        与ip_hash类似，但是按照访问url的hash结果来分配请求，使得每个url定向到同一个后端服务器，主要应用于后端服务器为缓存时的场景下。

        upstream backend {

            server 192.168.1.101;

            server 192.168.1.102;

            server 192.168.1.103;

             hash $request_uri;

             hash_method crc32;

        }

         其中，hash_method为使用的hash算法，需要注意的是：此时，server语句中不能加weight等参数。

         关于，如何在负载均衡中使用upstream请参看这里。

具体nginx.conf配置说明：

########### 每个指令必须有分号结束。#################

#user administrator administrators;  #配置用户或者组，默认为nobody nobody。

#worker_processes 2;  #允许生成的进程数，默认为1

#pid /nginx/pid/nginx.pid;   #指定nginx进程运行文件存放地址

error_log log/error.log debug;  #制定日志路径，级别。这个设置可以放入全局块
9064
，http块，server块，级别以此为：debug|info|notice|warn|error|crit|alert|emerg

events {

    accept_mutex on;   #设置网路连接序列化，防止惊群现象发生，默认为on

    multi_accept on;  #设置一个进程是否同时接受多个网络连接，默认为off

    #use epoll;      #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport

    worker_connections  1024;    #最大连接数，默认为512

}

http {

    include       mime.types;   #文件扩展名与文件类型映射表

    default_type  application/octet-stream; #默认文件类型，默认为text/plain

    #access_log off; #取消服务日志    

    log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定义格式

    access_log log/access.log myFormat;  #combined为日志格式的默认值

    sendfile on;   #允许sendfile方式传输文件，默认为off，可以在http块，server块，location块。

    sendfile_max_chunk 100k;  #每个进程每次调用传输数量不能大于设定的值，默认为0，即不设上限。

    keepalive_timeout 65;  #连接超时时间，默认为75s，可以在http，server，location块。

    upstream mysvr {   

      server 127.0.0.1:7878;

      server 192.168.10.121:3333 backup;  #热备

    }

    error_page 404 https://www.baidu.com; #错误页

    server {

        keepalive_requests 120; #单连接请求上限次数。

        listen       4545;   #监听端口

        server_name  127.0.0.1;   #监听地址       

        location  ~*^.+$ {       #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。

           #root path;  #根目录

           #index vv.txt;  #设置默认页

           proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表

           deny 127.0.0.1;  #拒绝的ip

           allow 172.18.5.54; #允许的ip           

        } 

    }

}

项目应用描述：

我们发现我们云平台停车这个项目部署之后，发现用户访问量增加了很多，这个时候我们的服务器就承载不了了，所以我们公司提出的解决方案就是搭建一个tomcat+Nginx的应用服务器的集群

这么搭建的好好处就是我们的用户请求进来之后我们可以通过nginx的反向代理服务器来分配用户的请求去访问哪些tomcat服务器，我们在项目中应用的分配策略采是fair（第三方），

为什么要用这种呢，因为这种是现在nginx常用的分配策略，好处是他能接受请求之后选择出响应时间最快的服务器来进行响应，这样能尽快的回复用户的请求。

Ip_hash和url_hash我没具体研究过，还有就是为什么不选用轮询和权重。先来说不选用轮询，因为轮询是最基本的nginx分配策略，这种策略我觉的还是不太合理，如果其中几台服务器响应慢，还是影响了

访问速度，选用第二种权重的话，如果权重大的服务器用的多的话，其他的服务器反而没有更大程度的利用起来。

权重：举个例子

upstream mysvr {   

      server tomcat1 weight=1   1

      server tomcat2 weight=2   2,3

      server tomcat3 weight=3   4,5,6

    }

在这个时候，她会把这些数字123加起来，等于6，然后随机多少个访问，比如是25个，然后25%6+1，得到的数去访问（1）（2,3）（4，5，6）