Nginx负载均衡配置（一）

目录

负载均衡的意义

负载策略

内置策略

轮询策略

加权轮询策略

ip_hash策略

 扩展策略

url_hash策略

 fair策略

Sticky策略

---

负载均衡的意义

负载均衡的目的是为了解决单个节点压力过大，造成Web服务响应过慢，严重的情况下导致服务瘫痪，无法正常提供服务的问题。通常一个访问量非常大的Web网站（比如：淘宝、京东、12306等），由于一个Web服务同时能处理的用户并发请求的数量有限，同时还存在机器故障的情况，所以一个Web站点通常会在N台机器上各部署同一套程序。当某一个服务挂掉的时候，还有第二个、第三个、第N个服务。。。继续为用户提供服务，给用户的感觉，你的服务还在正常的运行！在这些提供同样服务的机器当中，在硬件配置方面也各不相同，这样就会存在部分机器性能非常好，能快速计算并响应用户的请求，另外一部份机器可能配置差点，响应用户的请求的时间会长一些。

这就需要我们思考一个问题？如果有一个服务正在同时处理1000个用户的请求，这个服务的上限可能最多能同时处理1000个用户的请求，这时它已经很忙了，如果此时又有一个新请求过来，我们仍然把这个请求分配给这台机器，这时候这个请求就只能在干等着，等这个服务处理完那些请求后，再继续处理它。这样在浏览器中的反应就像12306我们在春节买票一样，卡在那不动了，让用户眼巴巴的干着急。而能提供同样服务的其它机器，这时确很空闲。这样不仅是对服务器资源的浪费，也充分发挥不出弄多台服务器装同一个服务的最高价值。我们通常称对某一台机器的访问量为负载量，如何将一个用户的请求，合理的分配到一台能快速响应用户请求的服务器上，我们就需要用到一些负载策略。

负载均衡将用户的所有HTTP请求均衡的分配到每一台机器上，充分发挥所有机器的性能，提高服务的质量和用户体验。负载均衡可以通过负载均衡网络硬件设备(硬负载)和Web服务器软件(软负载)来实现，前者设备成本较高，小公司通常负担不起，所以后者一般是我们的首选。实现负载均衡常用的Web服务器软件有Nginx、HAProxy、LVS、Apache，本文主要介绍Nginx的负载均衡策。

负载策略

Nginx的upstream目前支持的6种方式的分配，分别是：轮询策略，权重轮询策略，ip_hash策略，fair策略，url_hash策略，sticky策略等。

这里将Nginx负载策略分为两大类，分别是：内置策略和扩展策略。

内置策略

Nginx负载均衡是通过upstream模块来实现的，内置实现了三种负载策略。官网负载均衡配置说明：http://nginx.org/en/docs/http/load_balancing.html

• 轮询策略（默认）
• 加权轮询策略
• ip_hash策略

轮询策略

顾名思义，该策略就是服务器将每个前端请求按顺序（时间顺序和排列次序）逐一分配到不同的后端服务器节点。如果后端服务器出现问题，即down掉，那么就会被自动剔除。配置示例如下：

upstream loadServer { #定义负载设备ip及其设备状态
    server 192.168.0.100:80; #做负载均衡的服务器地址B
    server 192.168.0.101:80; #做负载均衡的服务器地址C
    server 192.168.0.102:80; #做负载均衡的服务器地址D
}

加权轮询策略

该策略在轮询策略的基础上考虑各后端服务器节点接受请求的权重，指定后端各服务器节点被轮询到的几率，主要应用于后端服务器节点性能不均的情况。

通过直接配置weight来设置访问机率，weight的大小和访问比率成正比，如果不配置weight，则默认配置为weight=1

upstream loadServer { #定义负载设备ip及其设备状态
    server 192.168.0.100:80; #weight(权重),默认为1,权值越高被分配到的几率越大
    server 192.168.0.101:80; weight=3
    server 192.168.0.102:80; weight=2
}

注：因为weight是内置，所以可以直接和其他策略配合使用。

ip_hash策略

该策略通过将前端的访问IP进行HASH操作，然后根据HASH结果将请求分配到不同的服务器节点。当第一次请求时，根据该客户端的IP算出一个HASH值，将请求分配到集群中的某一台服务器上。后面该客户端的所有请求，都将通过HASH算法，找到之前处理这台客户端请求的服务器，然后将请求交给它来处理，配置示例如下：

upstream loadServer { #定义负载设备ip及其设备状态
    ip_hash;
    server 192.168.0.100:80; 
    server 192.168.0.101:80; weight=3
    server 192.168.0.102:80; weight=2
}

 扩展策略

 扩展策略需要依赖第三方完成，有以下3种：

• url_hash策略
• fair策略
• sticky策略。

url_hash策略

该策略将前端请求的url地址进行hash操作，根据hash结果将请求定向到同一后端服务器节点上，一般url_hash需要配合缓冲命中来使用。

1.7.2版本以后，url_hash模块已经集成到了nginx源码当中，不需要单独安装。之前的版本仍需要单独安装，下载地址：https://github.com/evanmiller/nginx_upstream_hash

应用场景：有一个服务器集群A，需要对外提供文件下载，由于文件上传量巨大，没法存储到服务器磁盘中，所以用到了第三方云存储来做文件存储。服务器集群A收到客户端请求之后，需要从云存储中下载文件然后返回，为了省去不必要的网络带宽和下载耗时，在服务器集群A上做了一层临时缓存（缓存一个月）。由于是服务器集群，所以同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。在此类场景下，为了使得缓存命中率提高，很适合使用url_hash策略，同一个url（也就是同一个资源请求）会到达同一台机器，一旦缓存住了资源，再次收到请求，就可以从缓存中读取，既减少了带宽，也减少了下载时间。

upstream loadServer { 
    hash $request_uri;
    server 192.168.0.100:80; 
    server 192.168.0.101:80; weight=3
    server 192.168.0.102:80; weight=2
}

 fair策略

该策略将请求转发到负载最小的后端服务器节点上。Nginx通过后端服务器节点对响应时间来判断负载情况，响应时间最短的节点负载就相对较轻，Nginx就会将前端请求转发到此后端服务器节点上。

由于fair模块是第三方提供的，在使用fair负载策略的时候需要先安装fair模块，具体可以参考：https://blog.51cto.com/445153/2334449

upstream loadServer { 
    server 192.168.0.100:80; 
    server 192.168.0.101:80; 
    server 192.168.0.102:80; 
    fair;
}

注：这种策略具有很强的自适应性，但实际的网络环境往往比较复杂，因此需要慎用。 

Sticky策略

该策略在多台服务器的环境下，为了确保一个客户端只和一台服务器通讯，它会保持长连接，并在结束会话后再次选择一个服务器，保证了压力均衡。

upstream loadServer {
    sticky; 
    server 192.168.0.100:80; 
    server 192.168.0.101:80;
    server 192.168.0.102:80;
}

注：如果浏览器不支持cookie，那么sticky不生效，毕竟整个模块是基于cookie实现。另外，Sticky模块和ip_hash模块不能够同时使用。