轉身呐喊妳
这个问题问得可就有点门外汉的意思了。。。
nginx作为一款负载均衡服务组件，凭借其近乎绝对稳定，性能优异等特性，成为企业级大应用中不可或缺的均衡工具！
nginx使用反向代理实现，在访问者(通常为浏览器)与应用服务器之间进行解耦，将收到的请求通过一定的负载均衡策略分配到不同的应用服务器上，原本使用一台服务器提供服务，现在通过这样的nginx集群应用服务，对外提供强大的，透明的服务，单一应用服务器的不稳定性也可完美解决！
由此可见，nginx是对外提供负载均衡的服务组件，可提供的负载均衡策略包括但不限于以下几种:
1，轮询:每台应用服务器平均的接受到请求。
默认方式:只要通过server配置了多台应用服务器，就能默认轮询！
2，weight:按照一定的权重，分配到不同的机器上不同的访问数。
通过weight＝4;这样的句式来配置！
3，ip_hash:通过ip进行hash进行访问服务器分配，可解决上诉轮询的session不在一台机器的情况
使用ip_hash开启！
4，fair:按照应用服务的响应时间动态分配服务器。
5，url_hash:通过url进行hash分配到应用服务器上。
一般选择那种负载均衡方式还需要通过业务，整个架构来确定，nginx基于简单配置，就可以实现强大的性能，是开发者不可或缺的强大工具，更多的技术分享，敬请关注。。
此生唯一
Nginx是一个开源、高性能、跨平台的HTTP Server，也可以用作反向代理、负载均衡和HTTP缓存服务器， 很多一线互联网公司用Nginx搭建分布式集群承接海量的用户请求。
Nginx有六种负载均衡算法以满足不同场景下的流量调度
1、加权轮询的调度算法
- nginx默认情况下是轮询调度算法，没有指定权重(weight)下默认是1，均匀的分发到后端每个实例上。
upstream backend {
# no load balancing method is specified for Round Robin server
backend1.example.com;
server backend2.example.com;
}
- 如果加入权重时，根据权重比例，将流量分发到后端实例上。
upstream backend {
server
backend1.example.com
weight=5;server backend2.example.com;
}
如上的配置backend1.example.com的权重被设置为 5，另一个的权重没设置，所以是默认值1。 所以这时候NGINX会以5：1的比例转发请求，即6个请求中，5个被放到了 backend1.example.com上， 有一个被发到了 backend2.example.com上。
2、基于最少连接数的调度算法
在这个模式下，一个请求会被 NGINX 转发到当前活跃请求数量最少的服务实例上：
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
我们用least_conn来指定最少连接优先算法, NGINX 会优先转发请求到现有连接数少的那一个服务实例上。
3、基于客户端IP Hash的调度算法
在IP Hash模式下，NGINX会根据发送请求的IP地的 hash值来决定将这个请求转发给哪个后端服务实例。被hash 的IP地址要么是IPv4地址的前三个16进制数或者是整个 IPv6地址。使用这个模式的负载均衡模式可以保证来自同一个 IP的请求被转发到同一个服务实例上。当然，这种方法在某一个后端实例发生故障时候会导致一些节点的访问出现问题。
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
如果某一台服务器出现故障或者无法进行服务，我们可以给它标记上down，这样之前被转发到这台服务器上的请求就会重新进行 hash 计算并转发到新的服务实例上:
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server
backend3.example.com
down;}
4、基于通用Hash的调度算法
这个模式允许管理员自定义hash函数的输入，比如:
upstream backend {
hash $reqeust_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
在这个例子中，我们以请求中所带的url为hash的输入。 注意到这里在hash那一行的最后加入了consistent(一致性哈希)这个关键词。这个关键词会使用一种新的hash算法ketama, 该算法会让管理员添加或删除某个服务实例的时候，只有一小部分的请求会被转发到与之前不同的服务实例上去，其他请求仍然会被转发到原有的服务实例上去。
5、基于随机的调度算法
顾名思义，每个请求都被随机(random)到某个服务实例上去:
upstream backend {
random;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
Random 模式还提供了一个参数two，当这个参数被指定时，NGINX会先随机地选择两个服务器(考虑 weight)，然后用以下几种方法选择其中的一个服务器:
1） `least_conn`: 最少连接数
2）`least_time=header(NGINX PLUS only)`: 接收到 response header 的最短平均时间
3） `least_time=last_byte(NGINX PLUS only)`: 接收到完整请求的最短平均时间
我们可以参考下面的一个例子:
upstream backend {
random two least_time=last_byte;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
当环境中有多个负载均衡服务器在向后端服务转发请求时，我们可以考虑使用Random模式，在只有单个负载均衡服务器时，一般不建议使用Random模式。
6、基于最短时间的调度算法
这是一个NGINX PLUS(NGINX的付费版) 才有的模式，可以将请求优先转发给平均响应时间较短的服务实例，它也有三个模式:
`header`: 从服务器接收到第一个字节的时间
`last_byte`: 从服务器接收到完整的 response 的时间
`last_byte inflight`: 从服务器接收到完整地 response 的时间（考虑不完整的请求）
例子：
upstream backend {
least_time header;
server backend1.example.com;
server backend2.example.com;
}
总结
NGINX提供了多种负载均衡模式，在实际使用中，需要根据实际业务需求去做尝试，分析日志来找到最适合当前场景的复杂均衡模式。
