Nginx系列--upstream模块的使用

这篇具有很好参考价值的文章主要介绍了Nginx系列--upstream模块的使用。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

原文网址:Nginx系列--upstream模块的使用_IT利刃出鞘的博客-CSDN博客

简介

说明

        本文介绍nginx的upstream模块的使用。

        nginx的upstream模块是用于负载均衡的。

upstream模块介绍

        Nginx的负载均衡功能依赖于ngx_http_upsteam_module模块,所支持的代理方式包括proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass和grpc_pass。

        gx_http_upstream_module模块允许Nginx定义一组或多组服务组,使用的可以通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组的名字上。upstream模块可以实现负载均衡,而且在一个节点故障的时候,配置了upstream时可以自动切换到正常工作的节点。

负载均衡方式

官方自带的负载均衡

  • ip_hash
    • 通过ip来计算hash值,根据hash值将分配到不同的机器中,同一个hash值会一直落在一台机器上(也就是同一个ip)。
  • weight
    • 通过设置权重值指定集群中不同机器的权重,权重越高,落到该机器的请求次数越多。
  • 轮询(默认
    • 将请求均匀的分配到集群中的每一台机器上。
  • 最小连接数:
    • least_conn是动态调度算法,会根据后端节点的连接数来决定分配情况,哪个机器连接数少就分发给它。

这几种方式优先级如下:

ip_hash > weight > 轮询 > 最小连接数

ip_hash优先级最高,若配置了ip_hash,其他三种配置就会失效,只会根据ip_hash策略。配置了weight也是同样,轮询和最小连接数会失效。

第三方负载均衡方式

  • 最短响应时间
    • 最短响应时间(fair)调度算法是动态调度算法,会根据后端节点服务器的响应时间来分配请求,响应时间短的优先分配。
    • Nginx 本身是不支持 fair 调度算法的,如果要使用这种调度算法,必须下载 Nginx 的相关模块 upstream_fair。
  • url_hash算法
    • url_hash算法是动态调度算法,按访问 URL 的 hash 结果来分配请求,使每个 URL 定向到同一个后端服务器,可以进一步提高后端缓存服务器的效率命中率。(多用于后端服务器为缓存时的场景下)。
    • Nginx 本身是不支持 rul_hash的,如果要使用这种调度算法,必须安装 Nginx 的hash 模块软件包。

示例

ip_hash

upstream demo {
    ip_hash;
    server 192.168.0.1:8080;
    server 192.168.0.2:9090;
}

server {
    listen 80;
    server_name test.xxx.com;
    location / {
       proxy_pass http://demo/;
    }
}

当请求test.xxx.com时,会匹配进入到location,proxy_pass指定了upstream,此时就会根据ip_hash,对当前的请求IP做hash计算,得到最终会落到那台机器上。以后同一个ip请求,都会落到这个机器上。在某些项目中,可以考虑用这种方式来解决session共享的问题。

weight

upstream demo {
        server 192.168.0.1:8080 weight 2;
        server 192.168.0.2:9090 weight 1;
}

server {
    # …… 同上面的示例
}


请求test.xxx.com时,会两次落在192.168.0.1:8080机器上,一次落在192.168.0.2:9090上。

轮询

轮询很简单,是默认的方式。如下:

upstream demo {
        server 192.168.0.1:8080;
        server 192.168.0.2:9090;   
}

请求会均匀的落在两台机器上。文章来源地址https://www.toymoban.com/news/detail-460388.html

least_conn

upstream show {
    least_conn;
    server 192.168.0.141 ;
    server 192.168.0.142 ;
}

到了这里,关于Nginx系列--upstream模块的使用的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 使用Nginx的upstream实现负载均衡,并配置https,避免Post请求类型转发后变为Get

    Nginx支持负载均衡,可以很方便的帮助我们进行水平扩容,upstream就是nginx中的负载均衡模块 当客户端发送请求时,会先到Nginx,然后Nginx会将请求分发到后台不同的服务器上。 如果后台的服务器群中有一个宕机了,那么Nginx会自动忽略这台服务器,不会将请求再次分发到这台

    2024年02月01日
    浏览(52)
  • Nginx-报错no live upstreams while connecting to upstream

    生产环境Nginx间歇性502的事故分析过程 客户端请求后端服务时一直报错 502 bad gateway ,查看后端的服务是正常启动的。后来又查看Nginx的错误日志,发现请求后端接口时Nginx报错 no live upstreams while connecting to upstream ,查看该错误的解释可以得到的结果是upstream中没有可以提供服

    2024年02月10日
    浏览(39)
  • nginx偶发502 no live upstreams while connecting to upstream

    客户截屏系统偶发报错 后台排查nginx后台偶尔大量报错 no live upstreams while connecting to upstream 在nginx服务器上nestat查看 发现存在大量的 TIME_WAIT状态的连接 问题表现在nginx与下游服务器的连接出现了异常,在突发流量以后由于TIME_WAIT状态的连接过多导致无法创建足够的连接。 为

    2024年02月09日
    浏览(33)
  • Nginx报错信息*upstream prematurely closed connection while reading responseheader from upstream’

    Nginx 报错信息 upstream prematurely closed connection while reading response header from upstream 通常意味着后端服务(在这种情况下是监听在 8089 端口的服务)在 Nginx 期望读取响应头的时候关闭了连接。这可能是由于几种原因造成的,包括后端服务崩溃、超时设置不当或资源限制。 要解决这

    2024年02月04日
    浏览(40)
  • 解决Nginx错误:Upstream prematurely closed connection while reading response header from upstream

    【nginx error log】 /var/log/nginx/error.log: 级别:error 类型: [other] 次数: 1 错误信息(只取第一条): upstream prematurely closed connection while reading response header from upstream, client: 50.30.156.24 server: xx requests: \\\"GET x HTTP/1.1\\\" upstream: \\\"x 在使用Nginx作为反向代理服务器时,可能会遇到这样的错误:“ups

    2024年02月03日
    浏览(40)
  • tengine/nginx https请求 转发 http upstream

    当前的互联网应用基本都要支持https协议,而当浏览器头通过https协议将请求发到到负责负载的nginx后,会由当前nginx再以http协议向后端upstream进行请求,之所以这么做是因为https协议的安全性也带来的额外的性能消耗。而源端基本都是在一个内网里面的,对于通讯协议的安全性

    2024年01月23日
    浏览(46)
  • nginx加权轮询,upstream,Keepalive,负载均衡实现案例

    1. nginx 加权轮询, weight是权重配置。

    2024年02月08日
    浏览(45)
  • nginx中多个server块共用upstream会相互影响吗

    nginx中经常有这样的场景,多个server块共用一个域名。 如:upstream有2个以上的域名,nginx配置两个server块,共用一个upstream配置。 那么,如果其中一个域名发生\\\"no live upstreams while connecting to upstream\\\"错误,会不会影响另一个域名呢? 会。导致另一个域名会返回5xx,并且也报错

    2024年01月16日
    浏览(35)
  • NGINX [upstream timed out (110: Connection timed out) while reading response header from upstream]错误

    最近负责的项目生产环境久不久会报响应异常的错误,查看相应的NGINX有持续几分钟的连接超时的日志,如下: 查看相应的access日志,相应时间的请求没有响应码,再看没有响应前的请求日志,发现有几笔持续请求超过设定时长5S的响应时间的请求。查看应用服务器的TCP请求

    2024年02月15日
    浏览(43)
  • Nginx报错host not found in upstream解决办法

    项目说明 前后台分离项目,后台所属空间没有存储图片,放置前台空间存储,后台需要查看图片,借助proxy_pass。对应配置如下 test.conf test.htaccess 当初配置完成的时候,启动nginx并没有问题,但是重启系统之后,nginx却是启动不起来,报错为 如果依照报错去找答案,肯定会是

    2024年02月13日
    浏览(78)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包