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