nginx作为非常流行的反向代理软件，提供了几种负载均衡算法。
参考链接
https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash
一、负载均衡算法
- round robin（默认）
- weight
- IP_hash
- url_hash（第三方）
- fair（第三方）
- least_conn最小连接数
1.round robin（默认）
轮询方式，依次将请求分配到各个后台服务器中，默认的负载均衡方式。 适用于后台机器性能一致的情况。 挂掉的机器可以自动从服务列表中剔除。
2.weight
根据权重来分发请求到不同的机器中，指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
upstream bakend {
server 192.168.0.14:8080 weight=10;
server 192.168.0.15:8080 weight=10;
}
3. IP_hash
根据请求者ip的hash值将请求发送到后台服务器中，可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题。ip_hash是使用ip地址的
前三段
进行hash运算，根据结果的不同，重定向到不同的服务器上。如果是内网的ip，算出的hashcode都是一样的，所以没有负载分担的效果。
例如：
upstream bakend {
ip_hash;
server 192.168.0.14:8080;
server 192.168.0.15:8080;
server 192.168.0.16:8080;
}
ip_hash虽好，但是有个问题是容易造成负载不均的情况，因为对源ip进行hash结果是不确定的。并且还有个很重要的tip：ip_hash使用的只有ip的前三段，比如192.168.0.14就只有192.168.0参与hash计算。所以使用此方法来解决session的问题不是特别完美。最好是利用redis这类共享存储来解决。
ip_hash当需要去掉某一台的时候，不要直接去除，否则可能造成大量的session失效，因为hash结果不对了。可以使用down的方式解决。当然在业务量小的时候修改也是完全可以的。
upstream bakend {
ip_hash;
server 192.168.0.14:8080 down;
server 192.168.0.15:8080;
server 192.168.0.16:8080;
}
ip_hash新增一台机器的时候，也会造成大量的session失效，所以最好在业务量很小的时候进行。
ip_hash是使用的普通的hash算法实现的，在新增机器或者减少机器的时候容易造成大量的session失效，于是可以使用第三方的一致性hash模块解决。参考链接
http://www.fblinux.com/?p=1432
https://github.com/replay/ngx_http_consistent_hash
consistent_hash $remote_addr 可以根据客户端ip映射
consistent_hash $request_uri 根据客户端请求的url映射
consistent_hash $根据客户端携带的参数进行映射
4.url_hash（第三方）
根据请求的url的hash值将请求分到不同的机器中，当后台服务器为根据url缓存的时候效率高。
在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。Nginx本身不支持url_hash，如果需要这种调度算法，则必须安装Nginx的hash软件包。
upstream backend {
server 192.168.0.14:8080;
server 192.168.0.14:8080;
hash $request_uri;
hash_method crc32;
}
hash $remote_addr consistent;
hash $request_uri;
hash $request_uri consistent;
5. fair（第三方）
根据后台响应时间来分发请求，响应时间短的分发的请求多。比 weight、ip_hash更加智能的负载均衡算法，fair算法可以根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间 来分配请求，响应时间短的优先分配。Nginx本身不支持fair，如果需要这种调度算法，则必须安装upstream_fair模块。
upstream backend {
fair;
server 192.168.0.15:8080;
server 192.168.0.16:8080;
}
6. 最小连接数
根据后端连接数的多少决定分发给哪一台
upstream backend {
least_conn;
server 192.168.0.15:8080;
server 192.168.0.16:8080;
}
二、upstream中的调度状态
在Nginx upstream模块中，可以设定每台后端服务器在负载均衡调度中的状态，常用的状态有：
- down，表示当前的server暂时不参与负载均衡
- backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的访问压力最低
- max_fails，允许请求失败的次数，默认1，当超过最大次数时，返回proxy_next_upstream模块定义的错误。
- fail_timeout，请求失败超时时间，默认10，在经历了max_fails次失败后，暂停服务的时间。max_fails和fail_timeout可以一起使用
Nignx负载均衡功能是通过upstream模块实现的，是基于内容和应用的7层交换负载均衡。Nginx负载均衡默认对后端服务器有健康检测能力，但是检测能力较弱，仅限于端口检测，在后端服务器比较少的情况下（10台及以下）负载均衡能力表现突出。与LVS负载均衡相比，LVS是基于四层的IP负载均衡技术，具有高性能、高可用、吞吐量大等优点，LVS在集群中表现更佳。
Nginx最大连接数问题
nginx 有一个 master，有四个 woker，每个 woker 支持最大的连接数 1024，支持的最大并发数是多少？
- 普通的静态访问最大并发数是： worker_connections * worker_processes /2，
- 而如果是 HTTP 作 为反向代理来说，最大并发数量应该是 worker_connections *worker_processes/4。