Nginx 负载均衡

原文地址：http://nginx.com/resources/admin-guide/load-balancer/

Nginx Load Balancing
nginx 负载均衡

This section describes how to use NGINX and NGINX Plus as a load balancer.

本章将讨论怎样使用Nginx和Nginx加做负载均衡器。

In This Section
本章包含

• Load balancing overview
• 负载均衡概览
• Proxying traffic to a group of servers
• 代理流量到server组
• Choosing a load balancing method
• 选择一个负载均衡方法
• Server weights
• server权值
• Server slow start
• server慢启动
• Enabling session persistence
• 开启会话持久
• Limiting the number of connections
• 限制连接数目
• Passive health monitoring
• 被动的健康检測
• Active health monitoring
• 主动的健康检測
• Sharing data with multiple worker processes
• 多工作进程共享数据
• Configuring load balancing using DNS
• 使用DNS配置负载均衡
• Runtime reconfiguration
• 实时重配置

Overview
概览

Load balancing across multiple application instances is a commonly used technique for optimizing resource utilization, maximizing throughput, reducing latency, and ensuring fault-tolerant configurations.

通常多个应用实例来做负载均衡是优化资源利用、最大化吞吐量、降低延迟、确保容错配置。

NGINX can be used as a very efficient HTTP load balancer in different deployment scenarios.

Nginx能够通过不同的部署方案作为很有效的HTTP负载均衡器。

Proxying Traffic to a Group of Servers

代理流量到server组

To start using NGINX with a group of servers, first, you need to define the group with the upstream directive. The directive is placed in the http context.

要開始在一组server里使用Nginx，首先，你得用 upstream 指令来定义一个组。这个指令放在http块里。

Servers in the group are configured using the server directive (not to be confused with the “server” block that defines a virtual server running on NGINX). For example, the following configuration defines a group named “backend” and consists of three server configurations (which may resolve in more than three actual servers):

分组里的服务器通过指令server配置（不要跟”server”块搞混淆了，那是用于定义虚拟主机的）。比如。以下这个配置定义了一个由三个服务器配置（也可能很多其它）组成的名为”backend”的分组。

http {
    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
}

To pass requests to a server group, the name of the group is specified in the proxy_passdirective (or fastcgi_pass, memcached_pass, uwsgi_pass, scgi_pass depending on the protocol). In the next example, a virtual server running on NGINX passes all requests to the “backend” server group defined in the previous example:

要发送请求给一个server组，使用 proxy_pass 指令来指定分组名（或者是依据协议使用fastcgi_pass, memcached_pass, uwsgi_pass, scgi_pass ）。

在下个样例中，一个跑在Nginx上的虚拟server发送全部请求到前一个样例中定义的”backend”server组。

server {
    location / {
        proxy_pass http://backend;
    }
}

The following example sums up the two examples above and shows proxying requests to the “backend” server group, where the server group consists of three servers, two of them run two instanses of the same application while one is a backup server, NGINX applies HTTP load balancing to distribute the requests:

以下这个样例综合了上述两个演示样例。将请求代理到”backend”server组，”backend”server组由三个server组成，当中两个执行同样的应用实例，一个为备用server，Nginx应用HTTP负载均衡来分发请求：

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

Choosing a Load Balancing Method
选择一个负载均衡方式

NGINX supports four load balancing methods:

Nginx支持四个负载均衡方法：

1、The round-robin method: requests are distributed evenly across the servers with server weights taken into consideration. This method is used by default:

1、轮循法：请求依据server权重均衡地分布到各server，这种方法为默认方法：

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

2、The least_conn method: a request is sent to the server with the least number of active connections with server weights taken into consideration:

2、least_conn法：请求被发送到激活连接数最少的server，server权重也为选择因素：

upstream backend {
    least_conn;

    server backend1.example.com;
    server backend2.example.com;
}

3、The ip_hash method: the server to which a request is sent is determined from the client IP address. In this case, either the first three octets of IPv4 address or the whole IPv6 address are used to calculate the hash value.

3、ip 哈希法：请求发送到哪个server取决于client的IP地址。

这样的情况下，使用IPv4 地址的前3个字节或者IPv6的整个地址用来计算哈希值。

The method guarantees that requests from the same address get to the same server unless it is not available.

这种方法能保证来自同一个地址的请求送到同一个server除非这个server不可用了。

upstream backend {
    ip_hash;

    server backend1.example.com;
    server backend2.example.com;
}

4、The generic hash method: the server to which a request is sent is determined from a user-defined key which may be a text, variable, or their combination. For example, the key may be a source IP and port, or URI:

4、通用哈希法：请求发送到哪个server取决于一个用户端定义的关键词。如文本，变量或两者组合。比如，这个关键词能够是来源IP和port。或者URI：

upstream backend {
    hash $request_uri consistent;

    server backend1.example.com;
    server backend2.example.com;
}

The optional consistent parameter of the hash directive enables ketama consistent hash load balancing. Requests will be evenly distributed across all upstream servers on the user-defined hashed key value. If an upstream server is added to or removed from an upstream group, only few keys will be remapped which will minimize cache misses in case of load balancing cache servers and other applications that accumulate state.

 hash 指令的可选的consistent參数开启ketama一致性哈希负载均衡。请求将会通过用户端定义的关键词的哈希值均衡地分发到上游分组，仅仅有少数几个关键词会被重映射以最小化负载均衡server和其它应用积累状态导致的缓存缺失。

If a method other than the default one is used, the corresponding directive (least_conn,ip_hash or hash) should be specified inside the upstream before the server directives.

假设要使用非默认的方法，对应的指令（least_conn,ip_has 或者 hash）必须放在upstream块里的server指令之前。

If one of the servers needs to be temporarily removed, it can be marked with the down parameter in order to preserve the current hashing of client IP addresses. Requests that were to be processed by this server are automatically sent to the next server in the group:

假设某个server须要暂时移除，能够使用down參数来标记它，当前正在哈希的clientIP地址得以保存。本该这个server处理的请求会自己主动地发送给本组中的下一个server：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}

Server Weights
server权重

By default, NGINX distributes requests among the servers in the group according to their weights using the round robin algorithm. The weight parameter of the server directive sets the weight of a server, by default, it is 1:

默认，Nginx依据server组里server的权重使用轮循算法为分发请求。server 指令的weight參数用来设置server的权重。此值缺省为1：

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

In the example, the first server has weight 5, the other two servers have the default weight (=1), but one of them is marked as a backup server and does not normally receive any requests. So of every six requests, five requests will be sent to the first server and one request will be sent to the second server.

本例中，第一个server权重为5，另外两个採用默认值1。可是当中一个被标记为备用server所以通常情况下不会接收请求。

所以每6个请求中。5个发送到第一个server1个发送到第二个server。

Server Slow Start
server慢启动

The server slow start feature prevents a recently recovered server from being overwhelmed by connections, which may timeout and cause the server to be marked as failed again.

server慢启动功能能防止刚刚恢复的server被大量连接超载导致server超时又被标为失败。

In NGINX, slow start allows an upstream server to gradually recover its weight from zero to its nominal value after it bas been recovered or became available. This can be done with the slow_start parameter of the server directive:

在Nginx中。慢启动能让上流服务器在全然恢复并可用之后逐渐把它的权重从0恢复到设置的值。这个或能 能够通过server指令的slow_start參数实现：

upstream backend {
    server backend1.example.com slow_start=30s;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

The time value sets the time for the server will recover its weight.

这个时间值设置了server恢复权重的时间。

Note that if there is only a single server in a group, max_fails, fail_timeout and slow_start parameters will be ignored and this server will never be considered unavailable.

注意假设分组里仅仅有一个server， max_fails, fail_timeout 和 slow_start參数会被忽略。而且这个server永远不会被判定为不可用。

Enabling Session Persistence
开启会话持久性

Session persistence means that NGINX identifies user sessions and routes the requests from this session to the same upstream server.

会话持久意思是Nginx认证用户会话而且把来自该会话的请求路由到同样的上游server。

NGINX supports three session persistence methods. The methods are set with the sticky directive.

Nginx支持三个会话持久方法。这三个方法使用sticky指令设置。

1、The  sticky cookie method. With this method, NGINX adds a session cookie to the first response from the upstream group and identifies the server which has sent the response. When a client issues next request, it will contain the cookie value and NGINX will route the request to the same upstream server:

1、sticky cookie 方法。

使用这种方法。Nginx加入一个会话cookie给第一个来自这个上游分组的响应，而且识别谁发送一个响应的server。当一个client发出下一个请求。请求会带着这个cookie值，Nginx将把这个请求路由到同样的上游server：

upstream backend {
    server backend1.example.com;
    server backend2.example.com;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

In the example, the  srv_id parameter sets the name of the cookie which will be set or inspected. The optional  expires parameter sets the time for the browser to keep the cookie. The optional  domain parameter defines a domain for which the cookie is set. The optional  path parameter defines the path for which the cookie is set. This is the simplest session persistence method.
本例中。 srv_id 參数设置用来设置或者检測的cookie名称。可选參数 expires指定浏览器保存这个cookie的时长。可选參数 domain定义cookie设置到的域名。可选參数path定义cookie的保存路径。

这是最简单的会话持久方法。

2、The sticky route method. With this method, NGINX will assign a “route” to the client when it receives the first request. All subsequent requests will be compared with the route parameter of the server directive to identify the server where requests will be proxied. The route information is taken from either cookie, or URI.

2、sticky route方法。

通过这种方法。Nginx在第一次接收到请求的时候给这个client分配一个“路由”。全部接下来的请求都会和server指令的route參数对照找出请求将被代理到的服务器。路由信息能够从cookie或URI中获取。

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

3、The  cookie learn method. With this method, NGINX first finds session identifiers by inspecting requests and responses. Then NGINX “learns” which upstream server corresponds to which session identifier. Generally, these identifiers are passed in a HTTP cookie. If a request contains a session identifier already “learned”, NGINX will forward the request to the corresponding server:

 3、cookie learn 方法。

Nginx首先通过检查请求和响应来查找会话ID。

接着Nginx就知道哪个上游server相应哪个会话ID。通常。这些ID是通过HTTP cookie传递的。假设一个请求包括一个已经识别过的会话ID，Nginx直接发送这个请求给相应的server：

upstream backend {
  server backend1.example.com;
  server backend2.example.com;

  sticky learn 
      create=$upstream_cookie_sessionid
      lookup=$cookie_sessionid
      zone=client_sessions:1m
      timeout=1h;
}

In the example, one of the upstream servers creates a session by setting the cookie “SESSIONID” in the response.
本例中，当中一个上游server通过在响应中设置cookie “SESSIONID” 来创建一个会话。
The obligatory parameter create specifies a variable that indicates how a new session is created. In our example, new sessions are created from the cookie “SESSIONID” sent by the upstream server.
必填參数create指定一个变量表示一个新的会话是怎样创建的。在我们的演示样例中。新的会话是通过上游server发送的cookie “SESSIONID”创建的。

The obligatory parameter lookup specifies how to search for existing sessions. In our example, existing sessions are searched in the cookie “SESSIONID” sent by the client.
必填參数lookup指定怎样搜索存在的会话。

演示样例中，存在的会话在client发送的cookie “SESSIONID”中搜索。

The obligatory parameter zone specifies a shared memory zone where all information about sticky sessions is kept. In our example, the zone is named client_sessions and has the size of 1 megabyte.
必填參数zone指定全部会话信息保存的共享内存空间。

我们这个样例中，空间名为client_sessions，大小为1M。
This is a more sophisticated session persistence method as it does not require keeping any cookies on the client side: all info is kept server-side in the shared memory zone.
这是一个更复杂的会话持久方法，由于他不须要在client保存不论什么cookie：全部信息保存在服务端的共享内存空间里。

Limiting the Number of Connections
限制连接数目

With NGINX Plus, it is possible to maintain the desired number of connections by setting the connection limit with the max_conns parameter.

使用Nginx加，能够通过max_conns參数设置连接限制维持所需的连接数量。

If the max_conns limit has been reached, the request can be placed into the queue for its further processing provided that the queue directive is specified. The directive sets the maximum number of requests that can be simultaneously in the queue:

假设max_conns设置的限制达到了，请求能够被放入队列进行queue指令提供的进一步的处理。queue指令设置了能够同一时候放入队列的最大请求数：

upstream backend {
    server backend1.example.com  max_conns=3;
    server backend2.example.com;

    queue 100 timeout=70;
}

If the queue is filled up with requests or the upstream server cannot be selected during the timeout specified in the optional timeout parameter, the client will receive an error.

假设队列排满或者在可选參数timeout设置的时间内无法选择上游server，client将接到一个错误。

Note that the max_conns limit will be ignored if there are idle keepalive connections opened in other worker processes. As a result, the total number of connections to the server may exceed the max_conns value in a configuration where the memory is shared with multiple worker processes.

注意假设闲置的keepalive连接在还有一个worker processes中打开了max_conns限制会被忽略。

导致的结果是。在多个工作进程共享内存的配置中，连接的总数可能会超过max_conns的值。

Passive Health Monitoring
被动式健康检測

When NGINX considers a server unavailable, it temporarily stops sending requests to that server until it is considered active again. The following parameters of the server directive configure the conditions to consider a server unavailable:

当Nginx觉得一台server不可用，就临时性的停止发送请求到这台server直到它再次被判定为可用。

以下这些server指令的參数用来配置推断一台server不可用的条件：

• The fail_timeout parameter sets the time during which the specified number of failed attempts should happen and still consider the server unavailable. In other words, the server is unavailable for the interval set by fail_timeout.
• fail_timeout 參数设置了在一定时间内，假设尝试失败的次数达到规定的数目，一直觉得该服务器不可用。换句话说。服务器在fail_timeout设置的时间间隔内不可用。
• The max_fails parameter sets the number of failed attempts that should happen during the specified time to still consider the server unavailable.
• max_fails參数设置在规定时间内发生的失败尝试的次数来判定服务器不可用。

The default values are 10 seconds and one attempt. So if NGINX fails to send a request to some server or does not receive a response from this server at least once, it immediately considers the server unavailable for 10 seconds. The following example shows how to set these parameters:

默认值为10秒钟一次尝试。就说假设Nginx发送请求到一个server或者从一个server失败至少一次。这个server直接被觉得不可用10秒钟。下例展示怎样设置这些參数。

upstream backend {
    server backend1.example.com;
    server backend2.example.com max_fails=3 fail_timeout=30s;
    server backend3.example.com max_fails=2;
}

Next are some more sophisticated features for tracking server availability, which are available in the  commercial subscription of NGINX.

以下是一些更复杂的跟踪server可用性功能，这些功能在Nginx的商业订购中。

Active Health Monitoring
主动的健康检測

Periodically sending special requests to each server and checking for a response that satisfies certain conditions can monitor the availability of servers.

定期地发送一些特别的请求到每一个server。检測一个满足一些条件的响应来监视server的可用性。

To enable this type of health monitoring in your nginx.conf file the location that passes requests to the group should include the health_check directive. In addition, the server group should also be dynamically configurable with the zone directive:

要开启这类健康检測，在你的nginx.conf文件里发送请求到这个分组的location块里面必须包括health_check指令。另外，server组必须通过zone指令进行动态配置：

http {
    upstream backend {
        zone backend 64k;

        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
        server backend4.example.com;
    }

    server {
        location / {
            proxy_pass http://backend;
            health_check;
        }
    }
}

This configuration defines a server group and a virtual server with a single location that passes all requests to a server group. It also enables health monitoring with default parameters. In this case, every five seconds NGINX will send the “/” requests to each server in the backend group. If any communication error or timeout occurs (or a proxied server responds with the status code other than 2xx or 3xx) the health check will fail for this proxied server. Any server that fails a health check will be considered unhealthy, and NGINX will stop sending client requests to it until it once again passes a health check.

这个配置定义了一个server组。一个仅仅有一个location块的虚拟机，这个location里的全部请求都将发送到这个server组。

这个location还开启了參数为默认值的健康监视。这样子，每过五秒，Nginx会发送”/‘请求到每一个backend组里的server。假设哪个对话错误或者超时（或者哪个代理server响应里返回的状态码不是2或3开头的）那么这个代理server健康检測失败。不论什么一个健康检測为失败的server被觉得是不健康的，Nginx将停止发送client请求到这台server直到它再次被检測为健康。

The zone directive defines a memory zone that is shared among worker processes and is used to store the configuration of the server group. This enables the worker processes to use the same set of counters to keep track of responses from the servers in the group. The zone directive also makes the group dynamically configurable.

zone指令定义了一个在工作进程中共享的内存空间。该内存空间用于存储server组的配置。这能够让全部工作进程使用同一个计数器来跟踪这个分组里的server的响应。zone相同能让分组支持动态配置。

This behavior can be overridden using the parameters of the health_check directive:

这个行为能够通过health_check指令的參数覆盖：

location / {
    proxy_pass http://backend;
    health_check interval=10 fails=3 passes=2;
}

Here, the duration between two consecutive health checks has been increased to 10 seconds using the interval parameter. In addition, a server will be considered unhealthy after 3 consecutive failed health checks by setting the fails parameter to 3. Finally, using the passes parameter, we have made it so that a server needs to pass 2 consecutive checks to be considered healthy again.

此间，两次连续的健康检測的时间间隔被通过interval參数添加到10秒。另外 。通过设置fails參数为3，一个server在连续3次健康检測失败后被觉得不健康。最后，使用passes參数，我们让一个server连续两次检測为健康才被又一次觉得是健康的。

It is possible to set a specific URI to request in a health check. Use the uri parameter for this purpose:

要在健康检測请求中指定URI，使用uri參数 ：

location / {
    proxy_pass http://backend;
    health_check uri=/some/path;
}

The provided URI will be appended to the server domain name or IP address specified for the server in the upstream directive. For example, for the first server in the backend group declared above, a health check request will have the http://backend1.example.com/some/path URI.

提供的URI将加入到在upstream指令中server指令指定的服务器域名或者IP地址后面。

比如，上述backend分组中第一个server，健康检測的请求URI为"http://backend1.example.com/some/path”。

Finally, it is possible to set custom conditions that a healthy response should satisfy. The conditions are specified in the match block, which is defined in the match parameter of the health_check directive.

最后，也能够自己定义满足健康检測的条件。这些条件在match块里规定。match块在health_check指令的match參数里定义。

http {
    ...

    match server_ok {
        status 200-399;
        body !~ "maintenance mode";
    }

    server {
        ...

        location / {
            proxy_pass http://backend;
            health_check match=server_ok;
        }
    }
}

Here a health check is passed if the response has the status in the range from 200 to 399, and its body does not match the provided regular expression.

这里假设一个响应状态码在200到399之间，而且响应体里没有匹配上提供的正則表達式，那健康检測就算通过了。

The match directive allows NGINX to check the status, header fields, and the body of a response. Using this directive it is possible to verify whether the status is in the specified range, whether a response includes a header, or whether the header or body matches a regular expression. The match directive can contain one status condition, one body condition, and multiple header conditions. To correspond to the match block, the response must satisfy all of the conditions specified within it.

match指令能够让Nginx检測一个响应的状态码，头字段。以及主体内容。

通过这个指令能够实现。确认状态码是否在规定的范围内，一个响应是否包括一个头，或者响应头和响应体是否匹配一个正则式。

match指令能够包括一个状态码条件，一个响应体条件和多个响应头条件。要想符合match块，响应必须满足里面定义的全部条件。

For example, the following match directive looks for responses that have the status code 200, contain the “Content-Type” header with text/html exact value, and have the body that includes the text “Welcome to nginx!”:

比如，以下这个match指令查找这种响应。状态码为200，包括准确值为text/html的”Content-type”头，还有响应体要包括文本“Welcome to nginx!”：

match welcome {
    status 200;
    header Content-Type = text/html;
    body ~ "Welcome to nginx!";
}

In the following example using a !, conditions match responses that have the status other than 301, 302, 303, and 307 and do not include the “Refresh” header field.

以下这个样例使用了一个!，条件为匹配拥有301,302,303,307以外状态码和不包括”Refresh”头字段的响应。

match not_redirect {
    status ! 301-303 307;
    header ! Refresh;
}

Health checks can also be enabled for non-HTTP protocols, such as FastCGI, SCGI, uWSGI and memcached.

健康检測也能够在非HTTP协议里启用，比如FastCGI,SCGI,uWSGI和memecached。

Sharing Data with Multiple Worker Processes
多进程共享数据

If the upstream directive does not include the zone directive, each worker process keeps its own copy of the server group configuration and maintains its own set of related counters. The counters include the current number of connections to each server in the group and the number of failed attempts to pass a request to a server. As a result, the server group configuration isn’t changeable.

假设upstream指令不包括zone指令，每一个工作进程保存自己分组配置的拷贝。而且维护自己相关的一系统计算器。这些计数器包括了组里每一个server当前的连接数和尝试发送一个请求到一个server的失败次数。

其结果是，服务组的配置是不能改变的。

If the upstream directive does include the zone directive, the configuration of the server group is placed in a memory area shared among all worker processes. This scenario is dynamically configurable, because the worker processes access the same copy of the group configuration and utilize the same related counters.

假设upstream指令包括了zone指令。server分组的配置放在一个全部工作进程共享的内存区域里，这个方法是可动态配置的，由于全部工作进程訪问同一个分组配置的拷贝而且使用同一个相关计数器。

The zone directive is mandatory for health checks and runtime modification of the server group. However, other features of the server groups can benefit from the use of this directive as well.

对于server组的健康检測和执行时改动，zone指令是强制的。并且，server分组的其它功能也能够从该指令的使用中受益。

For example, if the configuration of a group is not shared, each worker process maintains its own counter for failed attempts to pass a request to a server (see the max_fails parameter). In this case, each request gets to only one worker process. When the worker process that is selected to process a request fails to transmit the request to a server, other worker processes don’t know anything about it. While some worker process can consider a server unavailable, others may still send requests to this server. For a server to be definitively considered unavailable, max_fails multiplied by the number of workers processes of failed attempts should happen within the timeframe set by fail_timeout. On the other hand, the zone directive guarantees the expected behavior.

比如，假设一个分组的配置不是共享的。每一个工作进程维护自己的一个请求到一个server的失败尝试次数（看max_fails參数）计数器。这种话。每一个请求仅仅到一个工作进程。当原本该处理这个请求的工作进程传送请求到server失败。其它工作进程根本不知道。当一个工作进程觉得一个server不可用的时候。其它工作进程仍然向该server发送请求。一个server被判定为不可用的条件就变成。在fail_timeout设置的时间内失败尝试的次数（为max_fails设置的值）乘上工作进程的数目。

换个方面说。zone 指令能保证预期的行为。

The least_conn load balancing method might not work as expected without the zone directive, at least on small loads. This method of load balancing passes a request to the server with the least number of active connections. Again, if the configuration of the group is not shared, each worker process uses its own counter for the number of connections. And if one worker process passes by a request to a server, the other worker process can also pass a request to the same server. However, you can increase the number of requests to reduce this effect. On high loads requests are distributed among worker processes evenly, and the least_conn load balancing method works as expected.

假设没有zone指令。least_conn 负载均衡方法也可能达不到预期的效果，至少在小负载上。这个负载均衡方法把请求发送给活跃连接数最小的server。又来了，假设一个分组的配置不是共享的，每一个工作进程使用自己连接数的计数器。

并且假设一个工作进程传送一个请求到一个server。其它工作进程也会发送请求到同样的server。然而，你能够添加请求数量来减少这个影响。

在高负载下，请求会平均地分布到各个工作进程。least_conn 负载均衡方法就如预期的工作了。

Setting the Size for the Zone
设置zone的大小

There are no exact settings due to quite different usage patterns. Each feature, such as sticky cookie/route/learn load balancing, health checks, or re-resolving will affect the zone size.

没有什么是准确的配置由于不同的使用方案差异十分之大。每个功能，比如sticky cookie/route/learn 负载均衡方法，健康检測，或者重解析都会影响zone的大小。

For example, the 256 Kb zone with the “sticky_route” session persistence method and a single health check can hold up to:

比如，256Kb 大的空间使用sticky_route会话持久方式和单健康检測可以支持：

• 128 servers (adding a single peer by specifying IP:port);
• 128个服务器（使用IP:port方式加入单个）；
• 88 servers (adding a single peer by specifying hostname:port, hostname resolves to single IP);
• 88个服务器（使用主机名:端口指定单个方式，当中。一个主机名解析为一个IP）。
• 12 servers (adding multiple peers by specifying hostname:port, hostname resolves to many IPs).
• 12个服务器（指定主机名:端口加入多个，主机名相应多个IP）。

Configuring Load Balancing Using DNS
使用DNS配置负载均衡

The configuration of a server group can be modified at run time using DNS.

这样的配置能够在执行时使用DNS改动server组。

NGINX Plus can monitor changes of IP addresses that correspond to a domain name of the server and automatically apply these changes to NGINX without its restart. This can be done with the resolver directive which must be specified in the http block, and the resolve parameter of the server directive in a server group:

Nginx加可以监測服务器的域名相应的IP地址的变化。而且在不重新启动Nginx的情况下应用这些变化。这功能可以通过resolver指令实现。该指令必须放在http块里，还有服务器组里server指令的resolve參数必须指定。

http {
    resolver 10.0.0.1 valid=300s ipv6=off;
    resolver_timeout 10s;

    server {
        location / {
            proxy_pass http://backend;
        }
    }
   
    upstream backend {
        zone backend 32k;
        least_conn;
        ...
        server backend1.example.com resolve;
        server backend2.example.com resolve;
    }
}

In the example, the resolve parameter of the server directive will preiodically re-resolve “backend1.example.com” and “backend2.example.com” servers into IP addresses. By default, NGINX re-resolves DNS records basing on their TTL, but the TTL value can be overridden with the valid parameter of the resolver directive, in our example it is 5 minutes.

本例中。server 指令的resolve參数会定期的重解析 “backend1.example.com” 和 “backend2.example.com”两个server的IP地址。默认，Nginx基于DNS和TTL重解析DNS记录，而TTL的被可以resolver指令中valid參数覆盖。本例为5分钟。

The optional ipv6=off parameter allows resolving only to IPv4 addresses, though both IPv4 and IPv6 resolving is supported.

可选參数 ipv6=off 设置仅仅解析IPv4地址，虽然IPv4和IPv6的解析都是支持的。

If a domain name resolves to several IP addresses, the addresses will be saved to the upstream configuration and load-balanced. In our example, the servers will be load balanced according to the least_conn load balancing method. If one or more IP addresses has been changed or added/removed, then the servers will be re-balanced.

假设一个域名解析为多个IP地址，这些地址会保存到上游和负载均衡的配置。在我们的样例中。这些server会通过least_conn负载求均衡方法进程负载均衡。假设一个或多个IP地址被改动了加入了或者删除了。这些server会被再均衡。

Runtime Reconfiguration
实时重配置

The configuration of a server group can be modified at run time using the special HTTP interface. A configuration command can be used to view all servers or a specific server in a group, modify parameter for a specific server, and add or remove servers.

一个server组的配置能够通过使用特殊的HTTP接口实时改动。一个配置命令能够用来查看一组server或组内当中一个server，改动某个server參数，加入或者删除server。

To reconfigure at runtime:

实时重配置：

• Specify the zone directive in the upstream directive that configures a group. The zone directive configures a zone in the shared memory. The configuration of the server group will be kept in this zone, so all worker processes will use the same configuration.
• 在配置分组的upstream指令中指定zone指令。zone指令在共享内存中配置一个空间。服务器组的配置将被保存在这个空间里，因此全部的工作进程使用同样的配置。

• Place the upstream_conf directive in a separate location. The access to this location should be restricted.
• 在单个的location块里使用upstream_conf指令，对这个location的訪问必须是受限的。

An example of this configuration:

演示样例配置：

http {
    ...
    # Configuration of the server group
    upstream appservers {
        zone appservers 64k;

        server appserv1.example.com      weight=5;
        server appserv2.example.com:8080 fail_timeout=5s;

        server reserve1.example.com:8080 backup;
        server reserve2.example.com:8080 backup;
    }

    server {
        # Location that proxies requests to the group
        location / {
            proxy_pass http://appservers;
            health_check;
        }

        # Location for configuration requests
        location /upstream_conf {
            upstream_conf;
            allow 127.0.0.1;
            deny all;
        }
    }
}

Here, the access to the second location is allowed only from the 127.0.0.1 address. Access from all other IP addresses is denied.

这里，第二个location仅仅同意来自 127.0.0.1地址的訪问，来自其它地址的訪问都被拒绝。

To pass a configuration command to NGINX, send an HTTP request by any means. The request should have an appropriate URI to get into the location that includes upstream_conf. The request should include the upstream argument set to the name of the server group. For example, to view all backup servers (marked with backup) in the group, send

要发送一个配置命令给Nginx，通过不论什么方式发送一个HTTP请求。这个请求应该有一个可以进入包括了upstream_conf的location的URI，还应该包括指定这个server组名的參数upstream。

比如，要查看该组内全部备份server（标记为backup）。发送

http://127.0.0.1/upstream_conf?upstream=appservers&backup=

To add a new server to the group, send a request with add and server arguments:

要加入一个服务器到组时，发送一个请求带着add和server參数：

http://127.0.0.1/upstream_conf?add=&upstream=appservers&server=appserv3.example.com:8080&weight=2&max_fails=3

To remove a server, send a request with the remove command and the id argument identifying the server:

要删除一个server，发送一个带着remove命令和能找到server的ID參数的请求：

http://127.0.0.1/upstream_conf?remove=&upstream=appservers&id=2

To modify a parameter of a specific server, send a request with the id argument identifying the server and the parameter:

要改动某一个server的參数，发送请求带着要改动的server的id參数来标记server和要改动的參数。

http://127.0.0.1/upstream_conf?upstream=appservers&id=2&down=

See the reference for more examples.

更点信息见引用。