Nginx作为负载均衡器upstream

Nginx中与proxy模块结合使用的模块中,最常用的当属upstream模块。upstream模块可定义一个新的上下文,它包含了一组upstream服务器,这些服务器可能被赋予了不同的权重、不同的类型甚至可以基于维护等原因被标记为down。

upstream模块常用的指令有:

ip_hash:基于客户端IP地址完成请求的分发,它可以保证来自于同一个客户端的请求始终被转发至同一个upstream服务器,实现会话保持;

keepalive:每个worker进程为发送到upstream服务器的连接所缓存的个数;

least_conn:最少连接调度算法;

server:定义一个upstream服务器的地址,还可包括一系列可选参数,如:

weight:权重;

max_fails:最大失败连接次数,失败连接的超时时长由fail_timeout指定;

fail_timeout:等待请求的目标服务器发送响应的时长;

backup:用于fallback的目的,所有服务均故障时才启动此服务器;

down:手动标记其不再处理任何请求;

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

测试环境

nginx:192.168.2.168

httpd1:192.168.2.169

httpd2:192.168.2.170

nginx配置http中定义:

    upstream webservice {

        server 192.168.2.169 weight=1 max_fails=2 fail_timeout=5s;

        server 192.168.2.170 weight=1 max_fails=2 fail_timeout=5s;

        server 127.0.0.1:8080 backup;

}

server中定义

        location ~* ^/bbs/ {

          proxy_pass http://webservice;

          proxy_set_header X-Real-IP $remote_addr;

        }

另外定义back server:

    server {

        listen 8080;

        server_name 127.0.0.1;

        root /web/errorpages;

        index index.html;

    }

负载负载均衡:

upstream模块的负载均衡算法主要有三种,轮调(round-robin)、ip哈希(ip_hash)和最少连接(least_conn)三种。

注意:ip_hash被使用时,back server不能使用,wegiht失效

测试中,停掉httpd1,nginx自动检查server健康状况,只负载到httd2,再次停掉httd2,会负载到back server;

使用ip_hash算法:

    upstream webservice {
        ip_hash;
        server 192.168.2.169 weight=1 max_fails=2 fail_timeout=5s;
        server 192.168.2.170 weight=1 max_fails=2 fail_timeout=5s;
    }

测试时只会负载到httpd2

此外,upstream模块也能为非http类的应用实现负载均衡,如下面的示例定义了nginx为memcached服务实现负载均衡之目的。

    upstream memcachesrvs {
        server 172.16.100.6:11211;
        server 172.16.100.7:11211;
    }

    server {
        location / {
        set $memcached_key "$uri?$args";
        memcached_pass memcachesrvs;
        error_page 404 = @fallback;
        }

        location @fallback {
                proxy_pass http://127.0.0.1:8080;
        }
    }
时间: 2024-10-19 04:10:11

Nginx作为负载均衡器upstream的相关文章

nginx,php-fpm,phpfastcgi,upstream实现负载均衡

应用的最前端是一台nginx服务器,所有静态的内容都由nginx来处理,而将所有php的请求都分摊到下游的若干台运行php fastcgi守护进程的服务器中,这样可以以一种廉价的方案来实现对系统负载的分摊,扩展系统的负载能力. 三台php fastcgi服务器的ip地址分别为: 172.16.236.110 , 172.16.236.111, 172.16.236.112 运行php fastcgi进程时,需要让php-cgi监听到服务器的局域网地址(分别如上所示),而不是之前一般都是监听的本地

Nginx 中的 upstream 与 subrequest 机制

概述 Nginx 提供了两种全异步方式与第三方服务进行通信:upstream 和 subrequest.upstream 在与第三方服务器交互时(包括建立 TCP 连接.发送请求.接收响应.关闭 TCP 连接),不会阻塞 Nginx 进程处理其他请求.subrequest 只是分解复杂请求的一种设计模式,它可以把原始请求分解为多个子请求,使得诸多请求协同完成一个用户请求,并且每个请求只关注一个功能.subrequest 访问第三方服务最终也是基于 upstream 实现的. upstream 被

nginx 报错 upstream timed out (110: Connection timed out)解决方案

nginx 作PHP的web接口服务器. 在线上发现时不时经常崩溃.504,导致接口访问无响应回复. 查看日志: [error] 11618#0: *324911 upstream timed out (110: Connection timed out) while reading response header from upstream, client:然后百度看到都是修改nginx配置,解决超时问题. large_client_header_buffers 4 16k; client_m

nginx 配置负载均衡器

下面是一段nginx以HTTP形式的反向代理代码 # 编辑nginx.conf文件添加如下代码 upstream http_ziyuan_xueceping_server_pool { server 192.168.0.102:92 weight=1 max_fails=2 fail_timeout=60s down; # 代理到102:92 server 192.168.0.103:92 weight=1 max_fails=2 fail_timeout=60s; # 代理到103:92 }

nginx+webpy 出现 upstream timed out

关于nginx配置webpy应用出现的错误 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.6.141, server: localhost, request: "POST /api/ HTTP/1.1", upstream: 解决方法: 在你的nginx主配置文件中的server下配置以下内容,如果你的nginx后面是

Nginx中的upstream 分配方法

轮询 轮询是upstream的默认分配方式,即每个请求按照时间顺序轮流分配到不同的后端服务器,如果某个后端服务器down掉后,能自动剔除. upstream www_cc_com { server 192.168.1.1:8001; server 192.168.1.2:8002; server 192.168.1.3:8003; }weight 指定轮询比率,weight和访问几率成正比,主要应用于后端服务器性能差异的场景下. upstream www_cc_com{ server 192.1

nginx 错误502 upstream sent too big header while reading response header from upstream

查看nginx的错误日志,得到以下错误信息:upstream sent too big header while reading response header from upstream按字面意思理解应该是upstream负载均衡的模块转发的header头超出限制值了,查看配置文件中的相关配置,并搜索相关信息. 网上同类型的错误原因,说是cookie携带的header太多了,让你设置: fastcgi_buffer_size 128k;fastcgi_buffers 8 128k; 优化这些配

nginx 502错误 upstream sent too big header while reading response header from upstream

原本的设置是 proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; 在这种配置下,使用fiddler进行抓包分析,发现只要请求的header的尺寸大于4378字节的时候就报502,当header在4377及以下的时候就正常了. 将配置更改为: proxy_buffer_size 64k;   proxy_buffers   32 32k;   proxy_busy_buffers_size 128k; 之后

Nginx Upstream Keepalive 分析 保持长连接

相关配置 Nginx Upstream长连接由upstream模式下的keepalive指令控制,并指定可用于长连接的连接数,配置样例如下: upstream http_backend {     server 127.0.0.1:8080;       keepalive 16; }   server {     ...       location /http/ {         proxy_pass http://http_backend;         proxy_http_vers