What is the upstream configuration and function of nginx?

Configuration example

upstream backend {
  server backend1.example.com    weight=5;
  server backend2.example.com:8080;
  server unix:/tmp/backend3;

  server backup1.example.com:8080  backup;
  server backup2.example.com:8080  backup;
}

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

Command

Syntax:	upstream name { ... }
Default:	—
Context:	http

Define a group of servers. These servers can listen on different ports. Furthermore, servers listening on TCP and UNIX domain sockets can be mixed.

Example:

upstream backend {
  server backend1.example.com weight=5;
  server 127.0.0.1:8080    max_fails=3 fail_timeout=30s;
  server unix:/tmp/backend3;
}

By default, nginx distributes requests to each server in a weighted rotation. In the above example, every 7 requests will be distributed in the following way: 5 requests are distributed to backend1.example.com, 1 request is distributed to the second server, and 1 request is distributed to the third server. If an error occurs while communicating with the server, the request will be passed to the next server until all available servers have been tried. If all servers return failure, the client will get a (failure) response from the last server it communicated with.

Syntax:	server address [parameters];
Default value:	—
Context:	upstream

Define the server's address address and other parameters. The address can be a domain name or an IP address, and the port is optional, or a path to a unix domain socket specifying the "unix:" prefix. If no port is specified, port 80 is used. If a domain name resolves to multiple IPs, multiple servers are essentially defined.

You can define the following parameters: weight=number sets the weight of the server. The default is 1. max_fails=number sets the number of failed attempts by nginx to communicate with the server. Within the time period defined by the fail_timeout parameter, if the number of failures reaches this value, nginx will consider the server to be unavailable. During the next fail_timeout period, the server will not be tried again. The number of failed attempts defaults to 1. Setting it to 0 will stop counting attempts and consider the server to be always available. You can configure what is considered a failed attempt via the directives proxy_next_upstream, fastcgi_next_upstream and memcached_next_upstream. When configured by default, the http_404 status is not considered a failed attempt. fail_timeout=time sets the time period for

• # to count the number of failed attempts. During this period, if the server fails for the specified number of attempts, the server is considered unavailable.

• The period of time during which the server is considered unavailable.

By default, the timeout is 10 seconds. backup is marked as a backup server. When the main server is unavailable, requests will be passed to these servers. down marks the server as permanently unavailable and can be used with the ip_hash directive.

example:

upstream backend {
  server backend1.example.com   weight=5;
  server 127.0.0.1:8080      max_fails=3 fail_timeout=30s;
  server unix:/tmp/backend3;

  server backup1.example.com:8080 backup;
}

Syntax:	ip_hash;
Default Value:	—
Context:	upstream

Specifies the load for the server group Balanced method, requests are distributed among servers based on the client's IP address. The first three bytes of the IPv4 address, or the entire IPv6 address, will be used as a hash key. This method ensures that requests from the same client will be passed to the same server. Except when the server is considered unavailable, these client requests will be passed to other servers, most likely the same server.

IPv6 addresses are supported starting from versions 1.3.2 and 1.2.2.

If one of the servers wants to be temporarily removed, the down parameter should be added. This preserves the current client IP address hash distribution.

Example:

upstream backend {
  ip_hash;

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

Starting from versions 1.3.1 and 1.2.2, the load balancing method of ip_hash only supports setting the server weight value.

Syntax:	keepalive connections;
Default value:	—
Context:	upstream

这个指令出现在版本 1.1.4.

激活对上游服务器的连接进行缓存。

connections参数设置每个worker进程与后端服务器保持连接的最大数量。这些保持的连接会被放入缓存。 如果连接数大于这个值时，最久未使用的连接会被关闭。

需要注意的是，keepalive指令不会限制nginx进程与上游服务器的连接总数。 新的连接总会按需被创建。 connections参数应该稍微设低一点，以便上游服务器也能处理额外新进来的连接。

配置memcached上游服务器连接keepalive的例子：

upstream memcached_backend {
  server 127.0.0.1:11211;
  server 10.0.0.2:11211;

  keepalive 32;
}

server {
  ...

  location /memcached/ {
    set $memcached_key $uri;
    memcached_pass memcached_backend;
  }

}

对于http代理，proxy_http_version指令应该设置为“1.1”，同时“connection”头的值也应被清空。

upstream http_backend {
  server 127.0.0.1:8080;

  keepalive 16;
}

server {
  ...

  location /http/ {
    proxy_pass http://http_backend;
    proxy_http_version 1.1;
    proxy_set_header connection "";
    ...
  }
}

另外一种选择是，http/1.0协议的持久连接也可以通过发送“connection: keep-alive”头来实现。不过不建议这样用。

对于fastcgi的服务器，需要设置 fastcgi_keep_conn 指令来让连接keepalive工作：

upstream fastcgi_backend {
  server 127.0.0.1:9000;

  keepalive 8;
}

server {
  ...

  location /fastcgi/ {
    fastcgi_pass fastcgi_backend;
    fastcgi_keep_conn on;
    ...
  }
}

当使用的负载均衡方法不是默认的轮转法时，必须在keepalive 指令之前配置。

针对scgi和uwsgi协议，还没有实现其keepalive连接的打算。

语法:	least_conn;
默认值:	—
上下文:	upstream

这个指令出现在版本 1.3.1 和 1.2.2.

指定服务器组的负载均衡方法，根据其权重值，将请求发送到活跃连接数最少的那台服务器。 如果这样的服务器有多台，那就采取有权重的轮转法进行尝试。

嵌入的变量

ngx_http_upstream_module模块支持以下嵌入变量：

$upstream_addr保存服务器的ip地址和端口或者是unix域套接字的路径。 在请求处理过程中，如果有多台服务器被尝试了，它们的地址会被拼接起来，以逗号隔开，比如： “192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”。 如果在服务器之间通过“x-accel-redirect”头或者error_page有内部跳转，那么这些服务器组之间会以冒号隔开，比如：“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”。$upstream_response_time以毫秒的精度保留服务器的响应时间，（输出）单位是秒。 出现多个响应时，也是以逗号和冒号隔开。$upstream_status保存服务器的响应代码。 出现多个响应时，也是以逗号和冒号隔开。$upstream_http_...保存服务器的响应头的值。比如“server”响应头的值可以通过$upstream_http_server变量来获取。 需要注意的是只有最后一个响应的头会被保留下来。

The above is the detailed content of What is the upstream configuration and function of nginx?. For more information, please follow other related articles on the PHP Chinese website!