Nginx反向代理DEmo

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模块。

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

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

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

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

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

proxy_buffer_size：设置缓冲区大小， 默认,该缓冲区大小等于指令proxy_buffers设置的大小。

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

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

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