前篇Nginx专题（1）：Nginx之反向代理及配置详细介绍了Nginx功能之一——反向代理。本篇文章将重点介绍Nginx功能之二——负载均衡。
为了增加对负载均衡的好感，我们先了解负载均衡能实现什么。
将多个云服务器节点绑定在一起提供统一的服务入口。故障转移，在意外发生的时候，可以增加一层保险，减少损失。降低上线运维复杂度，实现平滑上线。运维和开发同学都喜欢。下面正式进入主题。
一、Nginx的负载均衡策略负载均衡就是将请求“均衡”地分配到多台业务节点服务器上。这里的“均衡”是依据实际场景和业务需要而定的。
对于Nginx来说，请求到达Nginx，Nginx作为反向代理服务器，有绝对的决策权，可以按照规则将请求分配给它知道的节点中的一个，通过这种分配，使得所有节点需要处理的请求量处于相对平均的状态，从而实现负载均衡。
Nginx支持的负载均衡策略很多，比较重点的如下：
round robin(轮询)random(随机)weight(权重)fair(按响应时长，三方插件)url_hash(url的hash值)ip_hash(ip的hash值)least_conn(最少连接数)这么多的策略，非常不利于记忆和选择，我们不妨将这些常见的策略归类，分而化之，方便挑选。
第一类最佳实现weight(权重)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_hashurl_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支持一致性哈希进行分配Nginx支持一致性hash进行分配，也就是配置中consistent。
什么是一致性hash？为什么要引入这个机制？在生产环境下，业务节点经常会出现增加或减少的情况，就算这种增加或减少都是被动的，也可能会对hash分配产生影响。如何能够做到尽量减少影响呢？这时一致性hash被发明出来。
一致性hash解决两个问题：
分配特别不均匀；节点变动除了对分配到这个节点上的请求有影响，还会导致其他节点上的请求重新分配。1）如何解决分配不均的问题
将原来的每一个节点复制出N个虚拟节点，并且给这些虚拟节点都起个名字。