Nginx-使用以及几种负载均衡算法

Nginx (engine x)

是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。

Nginx 能做什么？

1. 正向代理

正向代理服务器是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。

比较典型的例子就是VPN服务器，用户可以利用代理用户器穿过防火墙来访问外部网络，如下图：

通俗来说就是：用户通过BOSS直聘平台来直接跟BOSS聊，找工作，相当于BOSS直聘这个平台是代理服务器，而BOSS则是后端服务器

2. 反向代理

反向代理服务器位于用户与目标服务器之间，但是对于用户而言，反向代理服务器就相当于目标服务器，即用户直接访问反向代理服务器就可以获得目标服务器的资源。

同时，用户不需要知道目标服务器的地址，也无须在用户端作任何设定。反向代理服务器通常可用来作为Web加速，即使用反向代理作为Web服务器的前置机来降低网络和服务器的负载，提高访问效率。

真实服务器地址不能被外界所访问，所以需要通过一台代理服务器来访问内部资源，相当于外界提供的一个接口

3. HTTP 服务器（动静分离等）

Nginx本身也是一个静态资源的服务器，当只有静态资源的时候，就可以用Nginx来做服务器。就像现在比较流行的动静分离，将动态资源和静态资源根据一定的规则来区分开，这样我们就可以根据静态资源特点来对它进行缓存。

对于静态资源比如图片，js，css等文件，我们则在反向代理服务器nginx中进行缓存。这样浏览器在请求一个静态资源时，代理服务器nginx就可以直接处理，无需将请求转发给后端服务器tomcat。

若用户请求的动态文件，比如servlet,jsp则转发给Tomcat服务器处理，从而实现动静分离。这也是反向代理服务器的一个重要的作用。

4. 负载均衡

将请求通过某些负载均衡算法来分摊到某个指定的服务器上进行处理

负载均衡模块-upstream

用于从”upstream”指令定义的后端主机列表中选取一台主机。
nginx先使用负载均衡模块找到一台主机，再使用upstream模块实现与这台主机的交互。

关于upstream的关键词：

1.down 表示单前的server暂时不参与负载

2.weight 默认为1.weight越大，负载的权重就越大。

3.max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误

4.fail_timeout:max_fails次失败后，暂停的时间。

5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

ip_hash;
server 192.168.0.12:9090 down; (down 表示单前的server暂时不参与负载)
server 192.168.0.12:8080 weight=2; (weight 默认为1.weight越大，负载的权重就越大)
server 192.168.0.12:6060;
server 192.168.0.12:7070 backup; (其它所有的非backup机器down或者忙的时候，请求backup机器) 

    #负载均衡
    upstream sunsite{
        server 192.168.0.12:80;
        server 192.168.0.12:81;
    }
    
	server {
            server_name 192.168.1.102;
            #反向代理
            location /main/ {
                    #配置upstream名称
                    proxy_pass http://sunsite/;
            }
    }

upstream 负载均衡算法：

负载均衡服务器的实现可以分成两个部分：

1、根据负载均衡算法和web服务器的IP列表来计算得到集群中某一台服务器的IP

2、将请求数据发送到该地址对应的服务器；

轮询（round robin）

默认按照轮询（Round Robin）的方式进行负载均衡，每个请求按照IP顺序分配到不同的后端服务器，会维护一个服务器列表，如果后端服务器down掉，可以将down掉的服务器剔除。

Nginx 会进行服务器健康状态监测，如果某台服务器挂掉了，用户请求就不会再跳转到挂掉的服务器上，避免了出现影响使用的情况

    upstream sunsite{
        server 192.168.0.12:80;
        server 192.168.0.12:81;
    }

缺点是可靠性低，和负载分配不均衡（如果后端服务器性能不一致的话）

加权轮询（Weighted Round Robin）

针对每台后端服务器性能不一致的情况，可以对性能较好的服务器进行侧重分配用户请求，对性能不高的服务器分配少一些用户请求：

    upstream sunsite{
        server 192.168.0.12:80 weight=7;
        server 192.168.0.12:81 weight=3;
    }

指定轮询几率，权重为 7 的A服务器访问几率会比权重为 3 的B服务器大

大概是10次 会访问7次A，剩下的3次才访问B

IP_Hash

根据请求来源的IP地址进行Hash计算，得到后端服务器，这样来自同一个IP的请求总是会落到同一台服务器上处理，以致于可以将请求上下文信息存储在这个服务器上，

同一个会话周期内共享使用（共享Session），实现会话粘滞

    upstream sunsite{
        ip_hash
        server 192.168.0.12:80;
        server 192.168.0.12:81;
    }

fair（第三方）

The Nginx fair proxy balancer enhances the standard round-robin load balancer provided
with Nginx so that it will track busy back end servers (e.g. Thin, Ebb, Mongrel)
and balance the load to non-busy server processes.

GitHub

fair采用的不是内建负载均衡使用的轮换的均衡算法，而是可以根据页面大小、加载时间长短智能的进行负载均衡。，也就是根据后端服务器时间来分配用户请求，响应时间短的优先分配。具体没研究过

    upstream sunsite { 
        fair; 
        server 192.168.0.12;
        server 192.168.0.12;
    } 

url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。具体没研究过

Nginx 配置文件

worker_processes  1; # 工作进程数，一般情况下可以和CPU核心数保持一致
error_log # nginx的错误日志
pid #启动的PID

events {
    worker_connections  1024; # 每个进程的最大连接数
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;  # 高效率传输文件的模式 
    keepalive_timeout  65; # 客户端请求超时时间

    server {
        listen       80;    #默认访问的端口80
        server_name  localhost;  #地址

        #优先级,优先匹配符合最高的，次优先级 ^~ /a，第三优先级为正则表达式，第四优先级为/
        location / {        
            root   html;
            index  index.html index.htm;
        }
        
        #当访问/a的时候，优先匹配/a，当访问/a/b的时候，优先匹配/
        location =/a {
            root   html;
            index  index.html index.htm;
        }

        #当访问/a的时候，优先匹配/a，当访问/a/b的时候，优先匹配^~ /a
        location ^~ /a {        
            root   html;
            index  index.html index.htm;
        }   
        
        #当访问/a的时候，优先匹配/a，当访问/a/b的时候，优先匹配^~ /a，当访问/b的时候，优先匹配~ /\w    
        #PS：/w匹配的是数字、字母、下划线 3种类型
        location ~ /\w {        
            root   html;
            index  index.html index.htm;
        }     
        
        #当访问/a的时候，优先匹配/a，当访问/a/b的时候，优先匹配^~ /a，当访问/b的时候，优先匹配~ /\w 
        #PS：当有两条匹配规则都能匹配上的时候，写在前面的会先匹配
        location ~ /[a-z] {     
            root   html;
            index  index.html index.htm;
        }
        
        error_page   500 502 503 504  /50x.html; #错误页面，当出现以上错误状态码的时候，转到50.html
        location = /50x.html {
            root   html;
        }

    }
    #负载均衡
    upstream sunsite{
        server 192.168.0.12:80 weight=1;
        server 192.168.0.12:81 weight=1;
    }
    
	server {
            server_name 192.168.1.102;
            #反向代理
            location /main/ {
                    proxy_pass http://sunsite/;
            }
    }
}

Nginx location匹配规则

• location = /uri

= 表示精确匹配，只有完全匹配上才能生效

• location ^~ /uri

^~ 开头对URL路径进行前缀匹配，并且在正则之前。

• location ~ pattern

开头表示区分大小写的正则匹配

• location ~* pattern

开头表示不区分大小写的正则匹配

• location /uri

不带任何修饰符，也表示前缀匹配，但是在正则匹配之后

• location /

通用匹配，任何未匹配到其它location的请求都会匹配到，相当于switch中的default