nginx upstream 调度策略

    博客分类:

  • nginx
nginxround-robin

之前一直使用nginx 的upstream,今天有个哥们问我,upstream的调动算法是什么,我说我还真没注意过,使用Haproxy的时候倒是注意过,回来一查,原来也是round-robin,下面是nginx 官方文档给出的说明:

This module provides simple load-balancing (round-robin and client IP) across backend servers.

Example:

Java代码
  1. upstreambackend{
  2. serverbackend1.example.com;
  3. serverbackend2.example.com;
  4. serverbackend3.example.comdown;
  5. serverbackend4.example.com;
  6. }
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。其算法如下:

Java代码
  1. j=i;
  2. do
  3. {
  4. j=(j+1)modn;
  5. i=j;
  6. returnSi;
  7. }while(j!=i);
  8. 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*.

Java代码
  1. upstreambackend{
  2. ip_hash;
  3. serverbackend1.example.com;
  4. serverbackend2.example.com;
  5. serverbackend3.example.comdown;
  6. serverbackend4.example.com;
  7. }
upstream backend {
ip_hash;
server   backend1.example.com;
server   backend2.example.com;
server   backend3.example.com  down;
server   backend4.example.com;
}

发表回复