nginx upstream 调度策略
 
- 
博客分类:
 - nginx
 
之前一直使用nginx 的upstream,今天有个哥们问我,upstream的调动算法是什么,我说我还真没注意过,使用Haproxy的时候倒是注意过,回来一查,原来也是round-robin,下面是nginx 官方文档给出的说明:
This module provides simple load-balancing (round-robin and client IP) across backend servers.
Example:
- upstreambackend{
 - serverbackend1.example.com;
 - serverbackend2.example.com;
 - serverbackend3.example.comdown;
 - serverbackend4.example.com;
 - }
 
upstream backend {
server   backend1.example.com;
server   backend2.example.com;
server   backend3.example.com  down;
server   backend4.example.com;
}
轮询调度算法(Round-Robin Scheduling)
 
轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器,从1开始,直到N(内部服务器个数),然后重新开始循环。
算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。
轮询调度算法流程
假设有一组服务器N台,S = {S1, S2, …, Sn},一个指示变量i表示上一次选择的服务器ID。变量i被初始化为N-1。其算法如下:
- j=i;
 - do
 - {
 - j=(j+1)modn;
 - i=j;
 - returnSi;
 - }while(j!=i);
 - returnNULL;
 
j = i;
do
{
j = (j + 1) mod n;
i = j;
return Si;
} while (j != i);
return NULL;
WiKi
 
In computing, "round-robin" describes a method of choosing a resource
 for a task from a list of available ones, usually for the purposes of load balancing
 .
 Such may be distribution of incoming requests to a number of
 processors, worker threads or servers. As the basic algorithm, the
 scheduler selects a resource pointed to by a counter from a list, after
 which the counter is incremented and if the end is reached, returned to
 the beginning of the list. Round-robin selection has a positive
 characteristic of preventing starvation
 ,
 as every resource will be eventually chosen by the scheduler, but may
 be unsuitable for some applications where affinity
 
 is desirable, for
 example when assigning a process to a CPU
 or in link aggregation
 .
当然nginx 不止提供这一种算法,还提供一种ip_hash的方法,这种方法把一个ip总是转发到同一个server上
 ip_hash 
 
This directive causes requests to be distributed between upstreams based on the IP-address of the client.
 The key for the hash is the class-C network address of the client.  This
 method guarantees that the client request will always be transferred to
 the same server. But if this server is considered inoperative, then the
 request of this client will be transferred to another server.  This
 gives a high probability clients will always connect to the same server.
It is not possible to combine ip_hash and weight methods for
 connection distribution.  If one of the servers must be removed for some
 time, you must mark that server as *down*.
- upstreambackend{
 - ip_hash;
 - serverbackend1.example.com;
 - serverbackend2.example.com;
 - serverbackend3.example.comdown;
 - serverbackend4.example.com;
 - }
 
upstream backend {
ip_hash;
server   backend1.example.com;
server   backend2.example.com;
server   backend3.example.com  down;
server   backend4.example.com;
}