负载均衡就是将请求均衡”地分配到多台业务节点服务器上。这里的“均衡”是依据实际场景和业务需要而定的。
对于Nginx来说，请求到达Nginx，Nginx作为反向代理服务器，有绝对的决策权，可以按照规则将请求分配给它知道的节点中的一个，通过这种分配，使得所有节点需要处理的请求量处于相对平均的状态，从而实现负载均衡。
Nginx支持的负载均衡策略很多，比较重点的如下：
-
round robin(轮询)
-
random(随机)
-
weight(权重)
-
fair(按响应时长，三方插件)
-
url_hash(url的hash值)
-
ip_hash(ip的hash值)
-
least_conn(最少连接数)
-
round robin(轮询)
-
random(随机)
轮询不用多说。这里的随机，其实在大量请求的情况下，按照概率的理论等同于轮询的方式。
轮询配置：
#默认配置就是轮询策略
upstream server_group {
server backend1.example.com;
server backend2.example.com;
}
随机配置：
upstream server_group {
random;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
-
weight(权重)
-
fair(按响应时长，三方插件)
-
least_conn(最少连接数)
让业务节点中性能更强的机器得到更多请求，这也是一个比较好的分配策略。
什么是性能更好的机器？这个问题也有很多的维度去考量。
-
从经验或硬件上分为高权重、低权重的机器。
-
按照节点请求的响应时长来决定是多分配请求，还是少分配请求。
-
按照保持的连接数。一般来说保持的连接数越多说明处理的任务越多，也是最繁忙的，可以将请求分配给其他机器处理。
权重配置：
upstream server_group {
server backend1.example.com weight=5;
#默认为不配置权重为1
server backend2.example.com;
}
响应的时长(fair)配置(需要在Nginx编译时加入nginx-upstream-fair模块)
upstream server_group{
fair;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
最少连接数(least_conn)配置：
upstream server_group {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
-
ip_hash
-
url_hash
很多请求都是有状态的，上一次请求到哪个业务节点，这次还要请求到哪台机器。比如常见的session就是这样一种有状态的业务。
这里Nginx提供了按照客户端ip的hash来作为用户的标示分配、url的hash作为分配标示的规则。本质上还是要找到用户的请求中不变的要素，抽离出来，这样就可以进行分配了。
ip_hash配置：
upstream server_group {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
url_hash配置：
upstream server_group{
hash $request_uri consistent;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
Nginx支持一致性hash进行分配，也就是配置中consistent。
在生产环境下，业务节点经常会出现增加或减少的情况，就算这种增加或减少都是被动的，也可能会对hash分配产生影响。如何能够做到尽量减少影响呢？这时一致性hash被发明出来。
一致性hash解决两个问题：
-
分配特别不均匀；
-
节点变动除了对分配到这个节点上的请求有影响，还会导致其他节点上的请求重新分配。
一致性hash通过引入虚拟节点解决分配不均问题，通过引入哈希环来降低节点变动对其他节点产生的影响。
upstream server_group {
server backend1.example.com ;
server backend2.example.com max_fails=3 fail_timeout=30s;
server backup1.example.com backup;
}
- max_fails=number
这个参数决定了多少次请求后端失败后会暂停这个业务节点，不再给它发新的请求，默认值是1。此参数需要配合fail_timeout一起用。
题外话：如何定义失败，有很多种类型，这里因为主要处理HTTP代理，所以更关注proxy_next_upstream。
proxy_next_upstream：主要定义了当服务节点出现状况时，会将请求发给其他节点，也就是定义了怎么算作业务节点失败。
- fail_timeout=time
决定了当Nginx认定这个节点不可用时，暂停多久。不配置默认就是10s。
把上面两个参数联合起来考虑就是：当Nginx发现发送到这个节点上的请求失败了3次的时候，就会把这个节点摘除，摘除时间是30s，30s后才会再次发送请求到这个节点上。
- backup
类似于switch语句中的default，当主要节点都挂了的时候，会把请求打到这个backup节点。这是最后一个救兵了。