Nginx 策略配置

假设有3个实例，分别是localhost：1234/1235/1236

1.Nginx.conf文件

　　http节点下的server节点

 server {
        keepalive_requests 120; #单连接请求上限次数。
        listen       8086;   #监听端口
        server_name  127.0.0.1;   #监听地址       
        location  ~*^.+$ {       #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。
           #root path;  #根目录
           #index vv.txt;  #设置默认页
           proxy_pass  http://localhost:1234;  #请求转向localhost:1234 定义的服务器列表
           #deny 127.0.0.1;  #拒绝的ip
           #allow 172.18.5.54; #允许的ip           
        } 
    }

这个配置就是，监听本机的8086端口，转发到1234端口。

 

2.启动nginx

 

 

 在安装目录下命令行输入start nginx启动，如果启动失败，可以去同目录下的log里查看error日志。

通过1,2步，其实就是为nginx配置了反向代理，客户访问8086，转向到了1234，客户接受到的响应内容都来自1234端口

 

3.轮询负载均衡　　

第1步只配置了一个实例1234，现在配上所有3个

upstream myservers {   
      server localhost:1234;
      server localhost:1235;
　　　　server localhost:1236;
    }
    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://myservers;  #请求转向mysvr 定义的服务器列表
           #deny 127.0.0.1;  #拒绝的ip
           #allow 172.18.5.54; #允许的ip           
        } 
    }

定义了一个myservers，放入所有实例的地址，重启nginx就行了。

 

 这样会轮询的方式向三个实例分发请求，默认就是这个策略。

4.权重负载均衡

有时候我们布置的多个实例，性能是不一样的，轮询机制可能没法完全发挥它们的性能，那么可以将策略设置成权重，即按能力分配。

 

upstream myservers {   
      server localhost:1234 weight=1;
      server localhost:1235 weight=3;
　　　　server localhost:1236 weight=9;
    }

 

这么设置就行了，权重越高，转发的几率越大。

5.IP分配
这个说实话不常用，设置也很简单,会根据ip地质hash到一个实例，从此这个ip会固定访问这个实例，除非这个实例失效，会重新hash，这里设置了ip_hash后，后面的权重就没效果了。

upstream myservers {  
　　　　ip_hash; 
      server localhost:1234 weight=1;
      server localhost:1235 weight=3;
　　　　server localhost:1236 weight=9;
    }

6.最少链接数
也不常用，并且会与权重策略冲突，这个策略是优先分配给链接数少的实例，避免个别实例压力过大。

upstream myservers {  
　　　　#ip_hash; 
　　　　least_conn;
      server localhost:1234;
      server localhost:1235 ;
　　　　server localhost:1236;
    }

另外还有
fair最短响应时间：哪个实例相应最快，优先转发给它。
url_hash url固定响应，当某个页面需要特别处理，可以设置，让访问这个页面的请求全部转发给一个固定的实例。

7.用户持久化问题

http是无状态协议，客户下次访问时，服务器不知道你是你，所以引入了cookie+session，可以识别客户身份。

但是对于集群，有个问题就是，客户信息可能是保存在A服务器上，下次客户访问，被Nginx转发到B服务器了，那么客户信息就丢失了。

如何解决这个问题？

1.1 ip_hash的策略，让同一个ip只访问一个服务器，这确实可以解决问题，但是容易出现单个服务器压力过大的问题，并不建议。

1.2 客户端携带信息，例如客户信息存放在cookie，多个服务器验证到cookie后直接可以识别客户信息，但是体积太大占用带宽，安全性也不够，也容易丢失。

1.3  session共享，只要提供了sessionId，就去sqlserver/api/redis去验证，即去一个所有服务器都能访问到的公共服务器中去验证客户信息及状态，这个用的也比较多。

引申一个小问题，多个服务器的之间是如何知道同一个sessionId的，这个是存放在cookie中，而cookie有跨域的问题。

原因是同源策略是针对域名，ip+不同端口号不限制。