nginx反向代理问题解析

2016年-01-26:nginx稳定版本为nginx-1.8.1,核心版本为nginx-1.9.10+,1.9+版本修复了诸多nginx的bug,新增了很多新功能,本文介绍nginx反向代理方面

nginx反向代理实现方式很简单:

http {
    upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

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

nginx常用调度算法:

  • round-robin:轮询,加权轮询,这是默认的调度算法
  • least-connected :最小连接调度
  • ip-hash:基于ip的哈希
  • hash:基于url的哈希

问题解析:

upstream myapp1 {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

这里默认采用的就是加权轮询,默认三台server的权重值都为1

nginx默认开启被动健康检测功能默认:

server srv1.example.com max_fails=1 fail_timeount=10

意思是:

某nginx进程里的一个线程读取upstream模块,发包给srv1,失败一次在10秒内就会认为这个server不可用

线程共享这个nginx进程的内存空间,所以,该进程里所有线程都会知道这个server死掉了,在10秒的周期内都不会发请求给它了

问题是:

进程直接内存空间是独立的,这样说来,一个进程里面的某个线程检测到的结果也只有该进程内有效,

而其余进程是不会知道这台server死掉的信息。

那么如果nginx同时开启4个进程,第一个进程里的某个线程检测到死了一台server,第二,三,四进程都需要重新检测,这样健康检测就显得比较鸡肋了。

大家应该会很容易想到,可以拿出一块共享的内存(进程直接内存共享),专门存放检测数据,这样所有进程就不会出现重复检测的问题,对,这就是1.9版本新增功能zone(定义shared memory)

解决方案:

Syntax:zone name [size];

                    
Default:—    
Context:upstream

                    
This directive appeared in version 1.9.0.
Defines the name and size of the shared
memory zone that keeps the group’s configuration and run-time state that are
shared between worker processes.
Several groups may share the same zone.
In this case, it is enough to specify the size only once.
Additionally,
as part of our commercial subscription,
such groups allow changing the group membership
or modifying the settings of a particular server
without the need of restarting nginx.
The configuration is accessible via a special location
handled byupstream_conf.

实现方法:

http {
    upstream myapp1 {
        zone myapp1 64k;        #64k可以支持几十台机器的规模,128k可以支持到上百台
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

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

补充一:nginx做反向代理的时候,经常会报502,503错误,很明显不是nginx的错误,而是后端代理的服务器出问题了或者说检测不到代理的后端服务器了

情况:

如果upstream模块里server定义的主机引用的是主机名,那么一旦这台被代理的主机ip发生变化,nginx是不会主动检测的,就会报502错误

解决方案:

resolve
monitors changes of the IP addresses
that correspond to a domain name of the server,
and automatically modifies the upstream configuration
without the need of restarting nginx (1.5.12).
The server group must reside in the shared memory.

实现方法

http {
    resolver 8.8.8.8 valid=30s; #定义主动解析upstream模块定义的主机域名的dns服务器,valid为生存周期,会替换dns的TTL

    upstream u {
        zone u 64k;
        ...
        server example.com resolve; #后面一定要加resolve
    }
}

补充二:slow_start=time定义慢启动周期

问题解析:

大并发情况下宕机的某台机器修复好重新上线工作后,如果立马遇到大并发任务会再次宕机

解决方案:慢启动

http {
upstream dynamic {
    server www1.example.com      weight=5 slow_start=30s; #在30s内会逐步提升www1主机的权重值
    server www2.example.com      weight=3;
    server www3.example.com      weight=2;
}

server {
    location / {
        proxy_pass http://dynamic;
        health_check;
    }
}
}

补充三:如果upstream里只定义一台server,那么nginx认为这台server永远可用,健康检测选项(max_fails=3 fail_timeout=10)都无效

问题:

你只有你要机器直接proxy_pass http://www1.example.com就可以了,没必要定义upstream

你只有一台机器被代理,如果还健康检测,那么检测它死掉了,nginx在fail_timeout定义的周期内都认为这台机器死掉不给它发包,你觉得合理吗???所以嘛,只一台被代理的机器,健康检测默认失效。

时间: 2024-10-07 03:55:59

nginx反向代理问题解析的相关文章

Nginx反向代理服務器解析

Nginx反向代理服務器     反向代理(reverse proxy)方式是指用代理服務器來接受Internet上的連接請求,然後將請求轉發給内部網絡中的上游服務器,從上游服務器上得到返回結果給internet上請求連接的客戶端,此時,代理服務器對外的表現就是一個web服務器. nginx具有强悍的高并發高負載能力,因此一般會作爲前端的服務器直接向客戶端提供靜態文件服務,但也有一些複雜.多變的業務不適合放到nginx服務器上,這時會用apache,tomcat等服務器來處理. nginx通常會

搭建nginx反向代理用做内网域名转发

基于域名的7层转发的实现(NAT+反向代理) 在实际办公网中,因为出口IP只有一个,要实现对外提供服务的话就必须得做端口映射,如果有多个服务要对外开放的话,这只能通过映射不同端口来区分,这在实际使用过程中非常的痛苦(记忆困难.一一对应关系也没有规律.访问的时候还得加端口),这个痛苦的问题用表格的形式来形象的描述如下: Public IP Public Port Number Internal IP Internal Port Number Note 1.1.1.1 80 192.168.1.10

学习Nginx反向代理实现简单负载均衡

 Nginx proxy作为Nginx的重要功能,使用nginx proxy基本可以实现一个完整的7层负载均衡.其特色如下:1.功能强大,性能卓越,运行稳定.2.配置简单灵活. Nginx proxy作为Nginx的重要功能,使用nginx proxy基本可以实现一个完整的7层负载均衡. 其特色如下: 1.功能强大,性能卓越,运行稳定. 2.配置简单灵活. 3.能够自动剔除工作不正常的后端服务器. 4.上传文件使用异步模式. 5.支持多种分配策略,可以分配权重,分配方式灵活 配置环境: 三台

linux-nginx服务nfs服务nginx反向代理三台web

一:nginx服务 1.二进制安装nginx包 [[email protected] ~]# systemctl disable firewalld  #关闭Firewalls自启动 Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. Removed symlink /etc/systemd/system/basic.target.wants/firewalld.service. [[ema

配置LANMP环境(7)-- 配置nginx反向代理,与配置apache虚拟主机

一.配置nginx反向代理 1.修改配置文件 vim /etc/nginx/nginx.conf 在35行http下添加一下内容: include /data/nginx/vhosts/*.conf; include /etc/nginx/upstream.conf; 2.在/etc/nginx/目录下新建 upstream.conf文件 vim upstream.conf upstream dev.test1.com { server 127.0.0.1(换成虚拟机ip):8080 weigh

nginx反向代理+keepalived

系统版本:D 2.6.32-431.el6.x86_64 虚拟机  :四台 环境准备:关闭selinux : 关闭iptables:          其中两台 nginx +keepalive已安装且正常:          另外两台的节点web工作正常: #为了更好的测试, web 1:www.22  web 2:www.23 : nginx安装: yum install pcre* -y yum install openssl openssl-devel -y useradd -s /sb

Nginx反向代理websocket配置实例

最近有一个需求,就是需要使用 nginx 反向代理 websocket,经过查找一番资料,目前已经测试通过,本文只做一个记录 复制代码 代码如下: 注: 看官方文档说 Nginx 在 1.3 以后的版本才支持 websocket 反向代理,所以要想使用支持 websocket 的功能,必须升级到 1.3 以后的版本,因此我这边是下载的 Tengine 的最新版本测试的 1.下载 tengine 最近的源码 复制代码 代码如下: wget http://tengine.taobao.org/dow

nginx反向代理proxy_set_header自定义header头无效的问题

###案例1环境nginx,linux,tomcat域名访问是走nginx给后端服务器处理的,问题是域名经过nginx访问直接不能获取到headers,直接tomcat访问可以那么问题肯定在nginx上无法处理headers的问题了, 经过查询上面资料得到是nginx的锅,hearders有下划线的锅,nginx设置underscores_in_headers on,参照上面配置说.就可以处理,测试:http://apistore.baidu.com/astore/toolshttpproxyA

Linux平台部署nginx反向代理实例

nginx有着优秀的代理性能,很多情况下,nginx常常被充当反向代理服务器负载后端应用web构建起一个高性能高可用的web集群(淘宝tengix ,京东的nginx集群都使用到了nginx反向代理功能),接下来给大家讲解Linux平台部署nginx反向代理实例. [本文档所介绍的内容适用于公司测试/生产等常见的nginx反向代理应用] 1. nginx环境部署前准备: 1.1相关软件以及系统 系统要求:Centos 6.0以上 (64位) 相关中间件:Nginx: 1.6.0 以上(包含1.6