正反向代理与分配策略

亮点描述：


简述：
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;  #制定日志路径，级别。这个设置可以放入全局块，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）

转载自https://blog.csdn.net/clf0311/article/details/71124722