轮询
nginx将所有请求均匀的分给集群中的每台服务器。
upstream test {
server 127.0.0.1:7001; # 等同于server 127.0.0.1:7001 weight=1;server 150.109.118.85:7001; # 等同于server 150.109.118.85:7001 weight=1;}
server {
listen 8081;
server_name localhost;
location / {
proxy_pass http://test/;
}
}upstream：定义一个服务集群。 proxy_pass: 将匹配的请求代理转发到proxy_pass后面配置的服务上，这里因为需要配置负载均衡，所以这里http://后面必须要跟上upstream定义的服务集群。
注意：upstream定义服务集群时，配置的服务地址只能是域名+端口或者ip+端口，不能带有协议和路径，否则nginx会报nginx: [emerg] invalid host in upstream这个错误信息。
加权（weight）
upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}前面两次请求都会转发到127.0.0.1:7001这个服务，后面一次请求会转发到150.109.118.85:7001这个服务，再后面两次转发到127.0.0.1:7001，。。。
最少连接数
文件位置：src/http/modules/ngx_http_upstream_least_conn_module.c
nginx请求分配给active_connection/weight最小的服务器。
upstream test {
least_conn;
server 127.0.0.1:7001 weight=1;
server 150.109.118.85:7001 weight=1;
}ip_hash
文件位置：src/http/modules/ngx_http_upstream_ip_hash_module.c
根据用户的ip，计算出一个hash值，如果负载均衡缓存中有这个hash对应的服务器，那就直接转发到对应的服务器上。
upstream test {
ip_hash;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}nginx使用ip_hash策略后，只要用户电脑的ip不变化，就会始终请求同一台业务服务。
应用场景：在实现文件上传功能时，要实现一个大文件上传，往往会将这个大文件分成多个片段，然后上传到服务器，如果使用前面给的策略，就会出现同一个文件的分片被上传到不同服务器，导致文件合并失败，不能达到预期效果。nginx使用ip_hash策略后，客户端只要上传了当前文件的一个片段，后续文件片段上传的时候，nginx通过计算ip的hash，自动把请求转发到hash对应的服务器。
hash
文件位置：src/http/modules/ngx_http_upstream_hash_module.c
可以进行hash计算的有remote_addr（客户端ip）（从测试结果上面看感觉可以直接替换掉ip_hash）、request_uri(请求uri)、args（请求参数），下面主要以request_uri的使用作为展示，其他两个使用都类似。
根据请求的uri计算出一个hash值，然后将该请求转发到一台服务器上面，后续请求通过hash计算后，如果有相同的hash，那么就会将该请求转发到该hash对应的服务器。
假设集群中某台服务器宕机后会发生什么情况：如果r1命中a服务器，r2会命中哪个服务器？。如果a服务器宕机，之前通过r1计算出来的哈希值与a服务器的对应关系会失效，并且r1会重新分发给b服务器。后续a服务器恢复正常后，r1还是会分配给b服务器。
upstream test {
hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}应用场景：所有请求相同的文件资源的请求都会被转发到同一个服务器，资源更容易命中缓存，减少宽带和资源下载时间。
consistent_hash
consistent_hash（一致性hash）这个模块使用方式和nginx内置的hash模块几乎相同。能够使用consistent_hash进行计算的内容和前面提到的nginx内置的hash模块一样，有remote_addr、request_uri、args。您可以在这里下载 ngx_http_consistent_hash，它是一个用于三方模块的软件。
upstream test {
consistent_hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}fair
响应时间短的服务优先分配请求。您可以在nginx_upstream_fair的下载页面获取该三方模块。这个模块上次更新是8年前，可能需要考虑下是否需要使用这个。
upstream test {
fair;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}测试中得出效果和轮询默认情况效果一样，暂时没有找到问题在哪。。。
负载均衡相关参数
down
标识down的服务器暂时不支持资源请求。
upstream test {
server 127.0.0.1:7001 down;
server 150.109.118.85:7001;
}上面负载均衡的例子中，因为127.0.0.1:7001标识为down，所以不会有请求转发到这个服务，所有的请求都会转发到150.109.118.85:7001这个服务。
weight
集群中服务的权重值，默认是1。在只有weight这一个影响条件下，且集群中服务都正常，nginx会将更多的请求转发到weight更大的服务。
upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}这个集群中127服务和150服务各处理的请求比例为2:1。
max_fails
允许服务处理请求时服务出错的次数，默认为1。当服务处理请求发生错误的次数超过max_fails时，后面的请求暂时不会转发到这台发生错误的服务。
upstream test {
server 127.0.0.1:7001 max_fail=1;
server 150.109.118.85:7001;
}fail_timeout
如果某个服务处理请求时发生错误的次数超过 max_fails，nginx 将暂时禁止将请求转发到该服务。当过去fail_timeout设置的时间以后，nginx会尝试将请求转发到刚才被禁止的服务，如果服务正常，那么后续的请求可以继续转发到这台服务，如果服务错误，那么继续等待fail_timeout时间后再来检测。fail_timeout默认时间是10s。
upstream test {
server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
server 150.109.118.85:7001;
}backup
备用服务器，当所有非backup服务发生错误被停用或者设置为down时，nginx会启用标识为backup的服务。
upstream test {
server 127.0.0.1:7001 backup;
server 150.109.118.85:7001;
}max_conns
这个功能存在于nginx商业版。同一服务同时处理请求的个数。防止服务因处理请求过多，服务器性能不足，发生宕机的情况。
upstream test {
server 127.0.0.1:7001 max_conns=10000;
server 150.109.118.85:7001;
}slow_start
这个功能存在于nginx商业版。当集群中错误服务等待fail_timeout时间后，nginx检测到这个服务能够正常使用后，再等待slow_start时间后，才正式使用这个服务。
upstream test {
server 127.0.0.1:7001 slow_start=30s;
server 150.109.118.85:7001;
}
