首页 > web应用 > Nginx反向代理配置
2015
06-17

Nginx反向代理配置

Nginx的反向代理模块Upstream,可以实现集群的负载均衡功能,假设后端有三个服务节点,用于提供Web服务,通过Nginx的调度实现三个节点的负载均衡。

一、Nginx配置

http   
{  
  upstream  tshare365{  
    server   192.168.12.181:80 weight=1 max_fails=3 fail_timeout=20s;  
    server   192.168.12.182:80 weight=1 max_fails=3 fail_timeout=20s;  
    server   192.168.12.183:80 weight=1 max_fails=3 fail_timeout=20s;  
  }  
 
  server  
  {  
    listen       80;  
    server_name  www.tshare365.com;  
    index index.htm index.html;  
    root  /web/www;    
 
location / {  
 proxy_pass http://tshare365; 
 #如果后端的服务器返回500、502、503、执行超时等错误,自动将请求转发到upstream负载均衡池中的另一台服务器,实现故障转移。 
 proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header;  
 proxy_redirect off;  
 proxy_set_header Host $host;  
 proxy_set_header X-Real-IP $remote_addr;  
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  
 proxy_connect_timeout 90;  
 proxy_send_timeout 90;  
 proxy_read_timeout 90;  
 proxy_buffer_size  4k;  
 proxy_buffers 4 32k;  
 proxy_busy_buffers_size 64k;  
 proxy_temp_file_write_size 64k;  
 }  
  }  
}

二、配置文件参数解释

Nginx的代理功能是通过http proxy模块来实现的。默认在安装Nginx时已经安装了http proxy模块因此可直接使用http proxy模块。

  1. proxy_set_header:设置由后端的服务器获取用户的主机名或者真实IP地址,以及代理者的真实IP地址。

  2. client_body_buffer_size:用于指定客户端请求主体缓冲区大小,可以理解为先保存到本地再传给用户。

  3. proxy_connect_timeout:表示与后端服务器连接的超时时间,即发起握手等候响应的超时时间。

  4. proxy_send_timeout:表示后端服务器的数据回传时间,即在规定时间之内后端服务器必须传完所有的数据,否则,Nginx将断开这个连接。

  5. proxy_read_timeout:设置Nginx从代理的后端服务器获取信息的时间,表示连接建立成功后,Nginx等待后端服务器的响应时间,其实是Nginx已经进入后端的排队之中等候处理的时间。

  6. proxy_buffer_size:设置缓冲区大小, 默认,该缓冲区大小等于指令proxy_buffers设置的大小。 

  7. proxy_buffers:设置缓冲区的数量和大小。nginx从代理的后端服务器获取的响应信息,会放置到缓冲区。

  8. proxy_busy_buffers_size:用于设置系统很忙时可以使用的proxy_buffers大小,官方推荐的大小为proxy_buffers*2。

  9. proxy_temp_file_write_size:指定proxy缓存临时文件的大小。

三、Nginx常用调度算法

提供轮询(round robin)、用户 IP 哈希(client IP)和指定权重 3 种方式

默认情况下,Nginx 会为你提供轮询作为负载均衡策略。例如,某一时段内的一连串访问都是由同一个用户 Michael 发起的,那么第一次 Michael 的请求可能是 backend2,而下一次是 backend3,然后是 backend1、backend2、backend3…… 在大多数应用场景中,这样并不高效。当然,也正因如此,Nginx 为你提供了一个按照 Michael、Jason、David 等等这些乱七八糟的用户的 IP 来 hash 的方式,这样每个 client 的访问请求都会被甩给同一个后端服务器。这样可以解决session共享的问题。具体的使用方式如下:

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

这种策略中,用于进行 hash 运算的 key。这样的方式保证一个 client 每次请求都将到达同一个 backend。当然,如果所 hash 到的 backend 当前不可用,则请求会被转移到其他 backend。

再介绍一个和 ip_hash 配合使用的关键字:down。当某个一个 server 暂时性的宕机(down)时,你可以使用“down”来标示出来,并且这样被标示的 server 就不会接受请求去处理。具体如下:

upstream backend {
    ip_hash;
    server backend1.example.com down;
    server backend2.example.com;
    server.backend3.example.com;
    }

还可以使用指定权重(weight)的方式,如下:

upstream  tshare365{  
    server   192.168.12.181:80 weight=1
    server   192.168.12.182:80 weight=4
    
  }

默认情况下 weight 为 1,对于上面的例子,第一个 server 的权重取默认值 1,第二个是 4,所以相当于第一个 server 接收 20% 的请求,第二接收 80% 的。要注意的是 weight 与 ip_hash 是不能同时使用的,原因很简单,他们是不同且彼此冲突的策略。

可以为每个 backend 指定最大的重试次数,和重试时间间隔。所使用的关键字是 max_fails 和 fail_timeout,这里注意了,这个健康状态监测并不能保证nginx后端代理服务的可用性,因为它只是监测后端服务的端口号,如果服务僵死了,那么还是会把请求转发过去,这样我们客户端访问就会出现错误,正对这个问题,我们可以使用Nginx的第三方模块  nginx_upstream_check_module 来解决这个问题,这个模块的安装与使用放到我们后面的文章中讲解  也就是我们上面的例子。

最大失败次数为 3,也就是最多进行 3 次尝试,且超时时间为 20秒

从 Nginx 的 0.6.7 版本开始,可以使用“backup”关键字。当所有的非备机(non-backup)都宕机(down)或者繁忙(busy)的时候,就只使用由 backup 标注的备机。必须要注意的是,backup 不能和 ip_hash 关键字一起使用。举例如下:

  upstream  tshare365{  
    server   192.168.12.181:80 weight=1 max_fails=3 fail_timeout=20s;  
    server   192.168.12.182:80 weight=1 max_fails=3 fail_timeout=20s;  
    server   192.168.12.183:80 backup;
  }


总结

  以上这些就是我们在Nginx做反向代理中经常用到的知识点,如果有任何疑问请留言!




最后编辑:
作者:tshare365
这个作者貌似有点懒,什么都没有留下。
捐 赠您的支持是博主写作最大的动力,如果您喜欢我的文章,感觉我的文章对您有帮助,请狠狠点击

留下一个回复