How to configure nginx load balancing

Polling

nginx distributes all requests evenly to each server in the cluster.

upstream test {
server 127.0.0.1:7001; # 等同于server 127.0.0.1:7001 weight=1;server 150.109.118.85:7001; # 等同于server 150.109.118.85:7001 weight=1;}

server {
listen 8081;
server_name localhost;

location / {
 proxy_pass http://test/;
}
}

upstream: Define a service cluster. proxy_pass: Forward the matching request proxy to the service configured behind proxy_pass. Because load balancing needs to be configured here, http:// must be followed by the service cluster defined by upstream.

Note: When upstream defines a service cluster, the configured service address can only be the domain name port or ip port, and cannot contain protocols and paths, otherwise nginx will report nginx: [ emerg] invalid host in upstreamThis error message.

Weighted

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

The first two requests will be forwarded to 127.0.0.1:7001, and the next request will be forwarded to 150.109.118.85 :7001This service is forwarded to 127.0.0.1:7001 twice. . .

Minimum number of connections

File location: src/http/modules/ngx_http_upstream_least_conn_module.c

nginx requests are assigned to the server with the smallest active_connection/weight.

upstream test {
  least_conn;
server 127.0.0.1:7001 weight=1;
server 150.109.118.85:7001 weight=1;
}

ip_hash

File location: src/http/modules/ngx_http_upstream_ip_hash_module.c

According to the user’s ip, calculate a hash value, if the load If there is a server corresponding to this hash in the balancing cache, it will be forwarded directly to the corresponding server.

upstream test {
  ip_hash;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

After nginx uses the ip_hash policy, as long as the IP of the user's computer does not change, it will always request the same business service.

Application scenario: When implementing the file upload function, to upload a large file, the large file is often divided into multiple fragments and then uploaded to the server. If the strategy given above is used, the same problem will occur. Fragments of a file were uploaded to different servers, causing the file merging to fail and the expected results could not be achieved. After nginx uses the ip_hash policy, the client only needs to upload a fragment of the current file. When subsequent file fragments are uploaded, nginx automatically forwards the request to the server corresponding to the hash by calculating the hash of the IP.

hash

File location: src/http/modules/ngx_http_upstream_hash_module.c

The remote_addr (client ip) that can be used for hash calculation (it seems OK from the test results) Directly replace ip_hash), request_uri (request uri), and args (request parameters). The following mainly uses the use of request_uri as a demonstration. The other two uses are similar.

Calculate a hash value based on the requested uri, and then forward the request to a server. After subsequent requests are calculated through hash, if there is the same hash, then the request will be forwarded to the hash. The corresponding server.

Assume what will happen after a server in the cluster goes down: If r1 hits server a, which server will r2 hit? . If server a goes down, the correspondence between the hash value previously calculated by r1 and server a will become invalid, and r1 will be redistributed to server b. After server a returns to normal, r1 will still be assigned to server b.

upstream test {
  hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

Application scenario: All requests for the same file resources will be forwarded to the same server, making it easier for resources to hit the cache, reducing bandwidth and resource download time.

consistent_hash

consistent_hash (consistent hash) This module is used in almost the same way as nginx’s built-in hash module. The content that can be calculated using consistent_hash is the same as the nginx built-in hash module mentioned earlier, including remote_addr, request_uri, and args. You can download ngx_http_consistent_hash here, which is a software for third-party modules.

upstream test {
consistent_hash $request_uri;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

fair

Service requests with short response times are allocated first. You can obtain this third-party module from the download page of nginx_upstream_fair. This module was last updated 8 years ago. You may want to consider whether you need to use this.

upstream test {
fair;
server 127.0.0.1:7001;
server 150.109.118.85:7001;
}

The test results show that the effect is the same as the default polling situation, and the problem has not been found yet. . .

Load balancing related parameters

down

The server identified by down temporarily does not support resource requests.

upstream test {
server 127.0.0.1:7001 down;
server 150.109.118.85:7001;
}

In the load balancing example above, because 127.0.0.1:7001 is identified as down, no request will be forwarded to this service, and all requests will be Forward to the service 150.109.118.85:7001.

weight

The weight value of the service in the cluster, the default is 1. Under the condition that only weight is affected, and all services in the cluster are normal, nginx will forward more requests to services with a larger weight.

upstream test {
server 127.0.0.1:7001 weight=2;
server 150.109.118.85:7001 weight=1;
}

The ratio of requests processed by service 127 and service 150 in this cluster is 2:1.

max_fails

The number of service errors allowed when the service processes requests, the default is 1. When the number of errors in service processing requests exceeds max_fails, subsequent requests will not be forwarded to the service where the error occurred.

upstream test {
server 127.0.0.1:7001 max_fail=1;
server 150.109.118.85:7001;
}

fail_timeout

如果某个服务处理请求时发生错误的次数超过 max_fails，nginx 将暂时禁止将请求转发到该服务。当过去fail_timeout设置的时间以后，nginx会尝试将请求转发到刚才被禁止的服务，如果服务正常，那么后续的请求可以继续转发到这台服务，如果服务错误，那么继续等待fail_timeout时间后再来检测。fail_timeout默认时间是10s。

upstream test {
server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
server 150.109.118.85:7001;
}

backup

备用服务器，当所有非backup服务发生错误被停用或者设置为down时，nginx会启用标识为backup的服务。

upstream test {
server 127.0.0.1:7001 backup;
server 150.109.118.85:7001;
}

max_conns

这个功能存在于nginx商业版。同一服务同时处理请求的个数。防止服务因处理请求过多，服务器性能不足，发生宕机的情况。

upstream test {
server 127.0.0.1:7001 max_conns=10000;
server 150.109.118.85:7001;
}

slow_start

这个功能存在于nginx商业版。当集群中错误服务等待fail_timeout时间后，nginx检测到这个服务能够正常使用后，再等待slow_start时间后，才正式使用这个服务。

upstream test {
server 127.0.0.1:7001 slow_start=30s;
server 150.109.118.85:7001;
}

The above is the detailed content of How to configure nginx load balancing. For more information, please follow other related articles on the PHP Chinese website!