Nginx 可以基于ngx_http_upstream_module模块，提供服务器分组转发、权重分配、状态监测、调度算法等高级功能。下面会介绍如何配置upstream来实现对后端多台服务器的轮流调度。
指令
#配置一个后端web服务器，配置在upstream内，至少要有一个server服务器配置。
server address [parameters];
#server支持的parameters如下：
#设置权重，默认为1,实现类似于LVS中的WRR,WLC等
weight=number
#给当前server设置最大活动链接数，默认为0表示没有限制
max_conns=number
#对后端服务器连续监测失败多少次就标记为不可用,默认为1次,当客户端访问时,才会利用TCP触发对探测后端服务器健康性检查,而非周期性的探测
max_fails=number
#对后端服务器的单次监测超时时间，默认为10秒
fail_timeout=time
#设置为备份服务器，当所有服务器不可用才会启用的服务器
backup
#标记为down状态，标记后代理服务器就认为它挂了
down
#当server定义的是主机名的时候，当A记录发生变化会自动应用新IP而不用重启Nginx
resolve
#基于指定请求报文中首部字段或者URI等key做hash计算，使用consistent参数，将使用ketama一致性hash算法，适用于后端是Cache服务器（如varnish）时使用consistent定义使用一致性hash运算，一致性hash基于取模运算。
hash KEY [consistent];
#基于用户请求的uri做hash
hash $request_uri consistent;
#基于cookie中的sessionid这个key进行hash调度,实现会话绑定
hash $cookie_sessionid
#源地址hash调度方法，基于的客户端的remote_addr(源地址IPv4的前24位或整个IPv6地址)做hash计算，以实现会话保持。
ip_hash;
#最少连接调度算法，优先将客户端请求调度到当前连接最少的后端服务器,相当于LVS中的WLC
least_conn;反向代理后端多台web服务器
首先自定义一组服务器，配置在http块内。这里的IP地址替换成你想反代的服务器。
http {
...
upstream webserver {
hash $request_uri consistent;
server 10.0.0.101:80 weight=1;
server 10.0.0.102:80 weight=1;
server 127.0.0.1:80 weight=1 backup;
}
...
}然后在server块里调用刚才定义的upstream
server {
...
listen 80;
location / {
root /var/www/html;
proxy_pass http://webserver;
}
...
}基于 hash 的调度算法
所谓基于hash的调度算法是这么实现的。当我们对一个数据进行哈希运算的时候，不同的数据得到的哈希值是不一样的。nginx会对KEY进行哈希运算，KEY的值可以人为指定，这个KEY可以是$request_uri（基于用户请求的uri做hash），也可以是$cookie_sessionid（基于cookie中的sessionid这个key进行hash调度,实现会话绑定）。
得到的哈希结果，除以总的权重，根据得到的余数来决定调度到哪一台后端服务器。
所以当我们将KEY设置成$request_uri的时候，如果客户端每次访问同一个uri，它们的哈希值结果是一样的，所以请求会被稳定调度到同一台后端服务器上。
但是随着业务的发展，总权重是可能发生变化的，后端服务器的数量也会发生变化，造成了调度的不稳定。导致本来应该调度到a服务器的，却调度到b服务器那里去了，原来保存在a服务器上的用户s缓存信息就因此失效了。
为了解决这个问题，一致性hash算法就产生了。
有四台后端服务器。假设KEY是$request_uri，当用户访问某个uri，nginx对它做哈希运算，得到一个结果。然后用结果对2的32次方取模，结果一定是0 到（2^32-1）之间的某一个数字。我们把这个数放在上图的圆环里。不同的uri会得到不同的数，位于圆环的不同位置。同时对后端服务器做哈希运算，同样对结果取模，得到某个数字（node1 2 3 4）同样是落在圆环的不同位置。当用户请求某个uri的时候，系统会按顺时针顺序从圆环一直往下找，找到离这个数最近的节点（node）来提供服务。这就是一致性hash算法的原理。
再看上图右边那个圆环，当后端增加了一台新服务器，我们同样对这台服务器做哈希运算，并且取模得到一个数（node5), 假设它位于node 4 和 node 2之间。这时候如果有新的请求过来，只有一小段范围内的用户请求会被影响，影响的范围很小，大部分的请求还是按照旧的方式去调度。可以看出这种算法在遇到变化时表现得更加的稳定。建议开启功能，开启的方法很简单，在KEY 后边加上一个consistent就完事了。
hash $request_uri consistent;
