详解nginx upstream 配置和作用

 更新时间:2019年07月10日 14:41:48   作者:mood  
这篇文章主要介绍了详解nginx upstream 配置和作用,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

配置例子

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;
  }
}

指令

语法: upstream name { ... }
默认值:
上下文: http

定义一组服务器。 这些服务器可以监听不同的端口。 而且,监听在TCP和UNIX域套接字的服务器可以混用。

例子:

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

默认情况下,nginx按加权轮转的方式将请求分发到各服务器。 在上面的例子中,每7个请求会通过以下方式分发: 5个请求分到backend1.example.com, 一个请求分到第二个服务器,一个请求分到第三个服务器。 与服务器通信的时候,如果出现错误,请求会被传给下一个服务器,直到所有可用的服务器都被尝试过。 如果所有服务器都返回失败,客户端将会得到最后通信的那个服务器的(失败)响应结果。

语法: server address [parameters];
默认值:
上下文: upstream

定义服务器的地址address和其他参数parameters。 地址可以是域名或者IP地址,端口是可选的,或者是指定“unix:”前缀的UNIX域套接字的路径。如果没有指定端口,就使用80端口。 如果一个域名解析到多个IP,本质上是定义了多个server。

你可以定义下面的参数:weight=number设定服务器的权重,默认是1。max_fails=number设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内,如果失败的次数达到此值,Nginx就认为服务器不可用。在下一个fail_timeout时间段,服务器不会再被尝试。 失败的尝试次数默认是1。设为0就会停止统计尝试次数,认为服务器是一直可用的。 你可以通过指令proxy_next_upstream、 fastcgi_next_upstream和memcached_next_upstream来配置什么是失败的尝试。 默认配置时,http_404状态不被认为是失败的尝试。fail_timeout=time设定

  • 统计失败尝试次数的时间段。在这段时间中,服务器失败次数达到指定的尝试次数,服务器就被认为不可用。
  • 服务器被认为不可用的时间段。

默认情况下,该超时时间是10秒。backup标记为备用服务器。当主服务器不可用以后,请求会被传给这些服务器。down标记服务器永久不可用,可以跟ip_hash指令一起使用。

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;
}

语法: ip_hash;
默认值:
上下文: upstream

指定服务器组的负载均衡方法,请求基于客户端的IP地址在服务器间进行分发。 IPv4地址的前三个字节或者IPv6的整个地址,会被用来作为一个散列key。 这种方法可以确保从同一个客户端过来的请求,会被传给同一台服务器。除了当服务器被认为不可用的时候,这些客户端的请求会被传给其他服务器,而且很有可能也是同一台服务器。

从1.3.2和1.2.2版本开始支持IPv6地址。

如果其中一个服务器想暂时移除,应该加上down参数。这样可以保留当前客户端IP地址散列分布。

例子:

upstream backend {
  ip_hash;

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

从1.3.1和1.2.2版本开始,ip_hash的负载均衡方法才支持设置服务器权重值。

语法: keepalive connections;
默认值:
上下文: 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变量来获取。 需要注意的是只有最后一个响应的头会被保留下来。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

相关文章

  • nginx设置资源请求目录的方式详解

    nginx设置资源请求目录的方式详解

    最近有一个需求.就是url指定路径下访问服务器的静态资源,这篇文章主要给大家介绍了关于nginx设置资源请求目录的相关资料,文中通过示例代码介绍的非常详细,需要的朋友可以参考下
    2022-05-05
  • 使用nginx+lua进行token鉴权的方法

    使用nginx+lua进行token鉴权的方法

    使用nginx和lua脚本实现对Minio服务器图片链接的token鉴权,通过反向代理隐藏真实IP,增强安全性,介绍了整个鉴权流程,包括nginx配置和lua脚本的具体实现,适用于需要保护图片不被未授权访问的场景
    2022-05-05
  • nginx日志格式分析以及修改详解

    nginx日志格式分析以及修改详解

    Nginx日志对于统计、系统服务排错很有用,下面这篇文章主要给大家介绍了关于nginx日志格式分析以及修改的相关资料,文中通过实例代码介绍的非常详细,需要的朋友可以参考下
    2022-04-04
  • 一文搞懂Nginx限流(简单实现)

    一文搞懂Nginx限流(简单实现)

    这篇文章主要介绍了一文搞懂Nginx限流(简单实现),小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2019-05-05
  • Nginx构建Tomcat集群的操作方法

    Nginx构建Tomcat集群的操作方法

    nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器,这篇文章主要介绍了Nginx构建Tomcat集群的问题,需要的朋友可以参考下
    2022-01-01
  • 开发环境服务器vs生产环境服务器:开发与生产须分明详解

    开发环境服务器vs生产环境服务器:开发与生产须分明详解

    开发环境服务器(如Vite)和生产环境服务器(如Nginx和Node.js)在职责和工作方式上存在显著差异,开发环境服务器专注于快速开发和调试,而生产环境服务器则强调稳定性和高并发处理,Vite适合开发环境,而Nginx和Node.js更适合生产环境
    2025-01-01
  • nginx+lua+redis实现降级的示例代码

    nginx+lua+redis实现降级的示例代码

    随着用户访问量的激增,网站或电商平台可能会面临系统超负载的问题,导致注册、下单、支付等功能出现问题,为保障核心服务的高可用性,可以采用降级策略,本文就来介绍一下nginx+lua+redis降级,感兴趣的可以了解学习
    2024-10-10
  • Nginx源码编译安装全过程

    Nginx源码编译安装全过程

    Nginx是一个高性能的HTTP和反向代理服务器,具有异步非阻塞机制和轻量级的特点,它适用于多种场景,如Web网站服务、虚拟主机、反向代理、负载均衡和Web缓存服务器,Nginx的配置简洁,使用方便,具有较高的稳定性和抗并发能力
    2026-01-01
  • nginx https反向代理tomcat的2种实现方法

    nginx https反向代理tomcat的2种实现方法

    这篇文章主要给大家介绍了关于nginx https反向代理tomcat的2种实现方法,第一种方法是nginx配置https,tomcat也配置https,第二种方法是nginx采用https,tomcat采用http,文中通过示例代码介绍的非常详细,需要的朋友可以参考下。
    2017-12-12
  • nginx优化与防盗链配置过程

    nginx优化与防盗链配置过程

    本文介绍了Nginx配置的最佳实践,包括隐藏版本号、分割日志文件、启用压缩、图片缓存、并发设置以及优化其他配置
    2026-03-03

最新评论