Nginx负载均衡策略

上游服务器集群的配置语法及说明

配置：	upstream serverxxx{     ## 负载策略 ##     server ip:port [params]     server ip:port [params]     ... }
默认：	-
Context	http

      负载策略主要有以下几种

策略	说明
Round Robin（轮询，支持加权设置）	将靖求轮流分配到不同的服务器，支持加权设置，weight值越大分配几率越高
least_conn（最少连接数，支持加权设置）	请求优先转发给当前连接数最少的服务器
ip_hash	按客户端ip的hash结果进行分配，同一客户端的请求将分配到同一服务器。 算法类似于：hashCode(ip) % 上游服务器集群数量。 　所以它受集群数量的影响，当upstream集群中有一台上游服务器暂时不可用，不能直接删除该配置，而是要down参数标识，确保转发策略的一贯性
random （v > 1.15.1）	将请求随机分配到服务器，同时支持服务器的权重设置

      params主要有 

参数	说明
weight	权重值，默认为1
max_conns	代理服务器最大的活动连接数，默认为0表示没有限制
fail_timeout	该时间段内转发失败max_fails次后就认为上游服务器暂时不可用，默认为10秒
max_fails	与fail_timeout配合使用，指在fail_timeout时间段内，如果向当前的上游服务器转发失败次数超过max_fails次，则认为在当前的fail_timeout时间段内这台上游服务器不可用。默认为1次
backup	将服务器标记为备用服务器，当所有主服务器不可以用时，它才会接收请求。ip_hash负载策略下该配置无效。
down	将服务器标记为不可用，即下线。只有在ip_hash策略下才有效

反向代理配置及说明

配置	location ...{         proxy_pass URL;         ... }  http/server/location {        ...                　　proxy_set_header field value;        proxy_method Method;        proxy_hide_header field;        ...    }

• proxy_pass URL：表示将请求转发到url指定的服务器，如前面配置的上游服务器集群http://serverxxx;
• proxy_set_header：用来重定义发往真实服务器的请求头。常用的主要有
  proxy_set_header Host $host;  Host的默认值为$proxy_host；即默认情况下反向代理转发的请求中host头部信息是代理服务器地址，而不是原请求中的Host头部信息。
  proxy_set_header X-Forward-For $remote_addr; 
  主要用来防止真实服务器在有防盗链或防攻击的情况下，代理服务器无法访问的情况。

  #配置前,Host值为$proxy_host
  "GET /start HTTP/1.0
  Host: serverxx
  
  #配置后,Host值为$host
  "GET /start HTTP/1.0
  Host: 192.168.218.128
  X-Forward-For: 192.168.218.1
  Connection: close

• proxy_method：转发时采用的方式，如POST、Get等

轮询（默认的负载策略）

http{
......
    server{
        listen 80;
        server_name localhost;
        location / {
                proxy_pass http://serverxx;
        }
    }

    upstream serverxx{
        server 10.129.0.197:8080;
        server 10.129.0.197:8081;
        server 192.0.0.1 backup;
    }
......
}

最少连接  
  配置与上类似，只是在upstream块中，添加一个least_conn标记；

upstream serverxx{
        least_conn;
        server 10.129.0.197:8080;
        server 10.129.0.197:8081;
        server 192.0.0.1 backup;
    }

  再次访问可从debug日志中看出，Nginx选用了least conn策略。 

2019/04/30 10:53:29 [debug] 19944#0: *356 http proxy header:
"GET /start HTTP/1.0
Host: serverxx
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

"
2019/04/30 10:53:29 [debug] 19944#0: *356 http cleanup add: 0000000001C9E840
2019/04/30 10:53:29 [debug] 19944#0: *356 init least conn peer
2019/04/30 10:53:29 [debug] 19944#0: *356 get least conn peer, try: 3
2019/04/30 10:53:29 [debug] 19944#0: *356 get least conn peer, many
2019/04/30 10:53:29 [debug] 19944#0: *356 stream socket 4
2019/04/30 10:53:29 [debug] 19944#0: *356 epoll add connection: fd:4 ev:80002005
2019/04/30 10:53:29 [debug] 19944#0: *356 connect to 10.129.0.197:8081, fd:4 #445

IP_HASH
　　backup表示该serve为备份服务器,只有当主服务器不可用时，它才会被传递请求，所以它不能算在ip_hash中有效服务节点中，这里将它移除。测试结果证明，同一客户端的请求映射到了同一上游服务器

upstream serverxx{
        ip_hash;
        server 10.129.0.197:8080;
        server 10.129.0.197:8081;        
    }

           

  Debug日志如下，从中看出IP_HASH策略生效

2019/04/30 11:05:29 [debug] 20003#0: *447 http proxy header:
"GET /start HTTP/1.0
Host: serverxx
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9

"
2019/04/30 11:05:29 [debug] 20003#0: *447 http cleanup add: 0000000001CD1390
2019/04/30 11:05:29 [debug] 20003#0: *447 get ip hash peer, try: 2
2019/04/30 11:05:29 [debug] 20003#0: *447 get ip hash peer, hash: 1 0002
2019/04/30 11:05:29 [debug] 20003#0: *447 stream socket 5
2019/04/30 11:05:29 [debug] 20003#0: *447 epoll add connection: fd:5 ev:80002005
2019/04/30 11:05:29 [debug] 20003#0: *447 connect to 10.129.0.197:8081, fd:5 #456

Nginx转发细节
        当客户端发来HTTP请求时，Nginx并不会立刻转发到上游服务器，而是先把用户的请求（包括HTTP包体）完整地接收到Nginx所在服务器的硬盘或者内存中，然后再向上游服务器发起连接，把缓存的客户端请求转发到上游服务器。而Squid等代理服务器则采用一边接收客户端请求，一边转发到上游服务器的方式。Nginx的这种工作方式有什么优缺点呢？很明显，缺点是延长了一个请求的处理时间，并增加了用于缓存请求内容的内存和磁盘空间。而优点则是降低了上游服务器的负载，尽量把压力放在Nginx服务器上，上游服务器不需要一开始就建立连接。
        而且通常客户端与代理服务器之间的网络会比较复杂，而代理服务器通常会与目标服务器处于同一网段，也就是说，通常情况下公网的传输耗时会比内网多，不需要一开始就建立连接，也就意味着服务器维护单个连接的时间在网络上就要短很多，当然对于客户端来言总耗时是不变的。