Nginx——负载均衡篇

Nginx 负载均衡

当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。
我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。

前言

提示：以下是本篇文章正文内容，下面案例仅供参考

一、负载均衡算法

轮询法：将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

源地址哈希法：根据获取客户端的IP地址，通过哈希函数计算得到一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

随机法：通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。

加权轮询法：不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

加权随机法：与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

最小连接数法：由于后端服务器的配置不尽相同，对于请求的处理有快有慢，最小连接数法根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

二、负载均衡的几种常用方式

每个服务的设备状态

down # 表示单前的server暂时不参与负载
weight# 默认为1.weight越大，负载的权重就越大。
max_fails=1 #允许请求失败的次数默认为1.当超过最大次数时，返回 proxy_next_upstream模块定义的错误
#max_fails=number 设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内，如果失败的
#次数达到此值，Nginx就认为服务器不可用。在下一个fail_timeout时间段，服务器不会再被尝试。 失败的尝试次数
#默认是1。设为0就会停止统计尝试次数，认为服务器是一直可用的。你可以通过指令proxy_next_upstream、 
#fastcgi_next_upstream和 memcached_next_upstream来配置什么是失败的尝试。 默认配置时，http_404状态不
#被认为是失败的尝试。
fail_timeout=60s  # 失败后，暂停的时间。
backup# 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

1.轮询

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

upstream debugo_servers {
        server 127.0.0.1:8080 ; 
        server 127.0.0.1:8081 ;
}

2.weight 权重值

weight根据服务器性能决定其大小,值越大，权重值越大，被访问到的几率越大

upstream debugo_servers {
        server 127.0.0.1:8080 weight=1; 
        server 127.0.0.1:8081 weight=2;
}

3.ip_hash

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream debugo_servers {
		ip_hash;
        server 127.0.0.1:8080 ; 
        server 127.0.0.1:8081 ;
}

4.fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream debugo_servers {
		 fair;
        server 127.0.0.1:8080 ; 
        server 127.0.0.1:8081 ;
}

5.url_hash（第三方）

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

upstream debugo_servers {
		hash $request_uri;
    	hash_method crc32;
        server 127.0.0.1:8080 ; 
        server 127.0.0.1:8081 ;
}

三、实战

1、网络架构

2、Nginx配置文件

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
	keepalive_timeout  65;
	upstream debugo_servers {
		ip_hash; 
		server localhost:8081 weight=5; 
		server localhost:8082 weight=10;
		server localhost:8083 weight=10;
	}
	server {
        listen       80;
        server_name  localhost;
		location / {
            root   html;
			try_files $uri $uri/ /index.html;
            index  index.html index.htm;
        }
		location /prod-api/{
			proxy_set_header Host $http_host;
			proxy_set_header X-Real-IP $remote_addr;
			proxy_set_header REMOTE-HOST $remote_addr;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_pass http://debugo_servers/;
		}
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

3、服务端配置

将服务以不用的端口启动即可

3、测试

根据日志可以看到，不同的访问到的服务会被Nginx分配到不同的服务上，将其中一个服务停止后，还是可以进行正常访问，只是页面端有有短暂的切换过程（Nginx切换服务导致的）。
问题：数据库服务器没有进行集群，承载的压力最会还是会聚集在数据库服务器上，所以后续优化可以考虑将数据库服务器进行读写分离、主从复制等降压操作。在生产环境中可以根据服务器配置、框架等等因素选择合适的负载均衡方案。

感谢以下作者提供的文章作为参考：
谷子吖
alterem