1.3 负载均衡算法(Load-Balancing Methods)

Problem

Round-robin load balancing doesn’t fit your use case because you

have heterogeneous workloads or server pools.

问题

对于负载压力不均匀的应用服务器或服务器连接池，轮询(round-robin)负载均衡算法

无法满足业务需求。

Solution

Use one of NGINX’s load-balancing methods, such as least connec‐

tions, least time, generic hash, or IP hash:

upstream backend {
    least_conn;
    server backend.example.com;
    server backend1.example.com;
}

This sets the load-balancing algorithm for the backend upstream

pool to be least connections. All load-balancing algorithms, with the

exception of generic hash, will be standalone directives like the pre‐

ceding example. Generic hash takes a single parameter, which can be

a concatenation of variables, to build the hash from.

解决方案

使用 NGINX 提供的其它负载均衡算法，如：最少连接数(least connections)、

最短响应时间(leaest time)、通用散列算法(generic hash)或 IP 散列算法(IP hash)：

upstream backend {
    least_conn;
    server backend.example.com;
    server backend1.example.com;
}

上面的 least_conn 指令为 upstream 所负载的后端服务，指定采用最少连接数

负载均衡算法实现负载均衡。所有的负载均衡算法指令，除了通用算列指令外，

都和上面示例一样是一个普通指令，需要独占一行配置。通用散列指令，接收一个

参数，也可以使一系列变量值的拼接结果，来构建散列值。

Discussion

Not all requests or packets carry an equal weight. Given this, round

robin, or even the weighted round robin used in examples prior, will

not fit the need of all applications or traffic flow. NGINX provides a

number of load-balancing algorithms that can be used to fit particu‐

lar use cases. These load-balancing algorithms or methods can not

only be chosen, but also configured. The following load-balancing

methods are available for upstream HTTP, TCP, and UDP pools:

结论

在负载均衡中，并非所有的请求和数据包请求都具有相同的权重。有鉴于此，

如上例所示的轮询或带有权重的轮询负载均衡算法，可能并不能满足我们的

应用或负载需求。NGINX 提供了一系列的负载均衡算法，以满足不同的运用

场景。所有提供的负载均衡算法都可以针对业务场景随意选择和配置，并且

都可以应用于 upstream 块级指令中的 HTTP、TCP 和 UDP 负载均衡服务器

连接池。

Round robin

The default load-balancing method, which distributes requests

in order of the list of servers in the upstream pool. Weight can

be taken into consideration for a weighted round robin, which

could be used if the capacity of the upstream servers varies. The

higher the integer value for the weight, the more favored the

server will be in the round robin. The algorithm behind weight

is simply statistical probability of a weighted average. Round

robin is the default load-balancing algorithm and is used if no

other algorithm is specified.

轮询负载均衡算法(Round robin)

NGINX 服务器默认的负载均衡算法，该算法将请求分发到 upstream 指令块

中配置的应用服务器列表中的任意一个服务器。可以通过应用服务器的负载

能力，为应用服务器指定不同的分发权重(weight)。权重的值设置的越大，将

被分发更多的请求访问。权重算法的核心技术是，依据访问权重求均值进行

概率统计。轮询作为默认的负载均衡算法，将在没有指定明确的负载均衡指令

的情况下启用。

Least connections

Another load-balancing method provided by NGINX. This

method balances load by proxying the current request to the

upstream server with the least number of open connections

proxied through NGINX. Least connections, like round robin,

also takes weights into account when deciding to which server

to send the connection. The directive name is least_conn.

最少连接数负载均衡算法(Least connections)

NGINX 服务器提供的另一个负载均衡算法。它会将访问请求分发到

upstream 所代理的应用服务器中，当前打开连接数最少的应用服务器

实现负载均衡。最少连接数负载均衡，提供类似轮询的权重选项，来决定

给性能更好的应用服务器分配更多的访问请求。该指令的指令名称是

least_conn。

Least time

Available only in NGINX Plus, is akin to least connections in

that it proxies to the upstream server with the least number of

current connections but favors the servers with the lowest aver‐

age response times. This method is one of the most sophistica‐

ted load-balancing algorithms out there and fits the need of

highly performant web applications. This algorithm is a value

add over least connections because a small number of connec‐

tions does not necessarily mean the quickest response. The

directive name is least_time.

最短响应时间负载均衡算法(least time)

该算法仅在 NGINX PLUS 版本中提供，和最少连接数算法类似，它将请求

分发给平均响应时间更短的应用服务器。它是负载均衡算法最复杂的算法

之一，能够适用于需要高性能的 Web 服务器负载均衡的业务场景。该算法

是对最少连接数负载均衡算法的优化实现，因为最少的访问连接并非意味着

更快的响应。该指令的配置名称是 least_time。

Generic hash

The administrator defines a hash with the given text, variables

of the request or runtime, or both. NGINX distributes the load

amongst the servers by producing a hash for the current request

and placing it against the upstream servers. This method is very

useful when you need more control over where requests are sent

or determining what upstream server most likely will have the

data cached. Note that when a server is added or removed from

the pool, the hashed requests will be redistributed. This algo‐

rithm has an optional parameter, consistent, to minimize the

effect of redistribution. The directive name is hash.

通用散列负载均衡算法(Generic hash)

服务器管理员依据请求或运行时提供的文本、变量或文本和变量的组合

来生成散列值。通过生成的散列值决定使用哪一台被代理的应用服务器，并

将请求分发给它。在需要对访问请求进行负载可控，或将访问请求负载到

已经有数据缓存的应用服务器的业务场景下，该算法会非常有用。需要注意

的是，在 upstream 中有应用服务器被加入或删除时，会重新计算散列进行

分发，因而，该指令提供了一个可选的参数选项来保持散列一致性，减少

因应用服务器变更带来的负载压力。该指令的配置名称是 hash。

IP hash

Only supported for HTTP, is the last of the bunch. IP hash uses

the client IP address as the hash. Slightly different from using

the remote variable in a generic hash, this algorithm uses the

first three octets of an IPv4 address or the entire IPv6 address.

This method ensures that clients get proxied to the same

upstream server as long as that server is available, which is

extremely helpful when the session state is of concern and not

handled by shared memory of the application. This method also

takes the weight parameter into consideration when distribut‐

ing the hash. The directive name is ip_hash.

IP 散列负载均衡算法(IP hash)

该算法仅支持 HTTP 协议，它通过计算客户端的 IP 地址来生成散列值。

不同于采用请求变量的通用散列算法，IP 散列算法通过计算 IPv4 的前

三个八进制位或整个 IPv6 地址来生成散列值。这对需要存储使用会话，

而又没有使用共享内存存储会话的应用服务来说，能够保证同一个客户端

请求，在应用服务可用的情况下，永远被负载到同一台应用服务器上。

该指令同样提供了权重参数选项。该指令的配置名称是 ip_hash。