nginx负载均衡

协议支持
Nginx工作在网络的7层，可以针对http应用本身来做分流策略。支持七层HTTP、HTTPS协议的负载均衡。对四层协议的支持需要第三方插件-yaoweibin的ngx_tcp_proxy_module实现了tcp upstream。
https://github.com/yaoweibin/nginx_tcp_proxy_module
此外，nginx本身也逐渐在完善对其他协议的支持：
Nginx 1.3.13 开发版支持WebSocket代理。

Nginx 1.3.15开发版支持SPDY。 2.2 均衡策略 nginx的负载均衡策略可以划分为两大类：内置策略和扩展策略。内置策略包含加权轮询和ip hash，在默认情况下这两种策略会编译进nginx内核，只需在nginx配置中指明参数即可。扩展策略有很多，如fair、通用hash、 consistent hash等，默认不编译进nginx内核。 加权轮询（weighted round robin） 轮询的原理很简单，首先我们介绍一下轮询的基本流程。如下是处理一次请求的流程图： Nginx负载均衡 图中有两点需要注意，第一，如果可以把加权轮询算法分为先深搜索和先广搜索，那么nginx采用的是先深搜索算法，即将首先将请求都分给高权重的机器，直 到该机器的权值降到了比其他机器低，才开始将请求分给下一个高权重的机器；第二，当所有后端机器都down掉时，nginx会立即将所有机器的标志位清成 初始状态，以避免造成所有的机器都处在timeout的状态，从而导致整个前端被夯住。 ip hash ip hash是nginx内置的另一个负载均衡的策略，流程和轮询很类似，只是其中的算法和具体的策略有些变化，如下图所示： Nginx负载均衡 ip hash算法的核心实现如下： for(i = 0;i < 3;i++){ hash = (hash * 113 + iphp->addr[i]) % 6271; }

p = hash % iphp->rrp.peers->number;

从代码中可以看出，hash值既与ip有关又与后端机器的数量有关。经过测试，上述算法可以连续产生1045个互异的value，这是该算法的硬限制。对 此nginx使用了保护机制，当经过20次hash仍然找不到可用的机器时，算法退化成轮询。因此，从本质上说，ip hash算法是一种变相的轮询算法，如果两个ip的初始hash值恰好相同，那么来自这两个ip的请求将永远落在同一台服务器上，这为均衡性埋下了很深的 隐患。

fair fair策略是扩展策略，默认不被编译进nginx内核。其原理是根据后端服务器的响应时间判断负载情况，从中选出负载最轻的机器进行分流。这种策略具有很强的自适应性，但是实际的网络环境往往不是那么简单，因此要慎用。 通用hash、一致性hash 这两种也是扩展策略，在具体的实现上有些差别，通用hash比较简单，可以以nginx内置的变量为key进行hash，一致性hash采用了nginx内置的一致性hash环，可以支持memcache。 2.2 配置示例 HTTP http {

upstream www.s135.com {

server 192.168.1.2:80;

server 192.168.1.3:80;

}

server{

listen 80;

server_name www.s135.com;

location / {

        proxy_pass        http://www.s135.com;

        proxy_set_header   Host             $host;

        proxy_set_header   X-Real-IP        $remote_addr;

        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

}

location /nginx_status {

        stub_status on;

        access_log off;

        allow 192.168.1.1;#设置为可访问该状态信息的ip

        deny all;

}

}

}

TCP – ngx_tcp_proxy_module

tcp {

upstream cluster {

 # simple round-robin

 server 192.168.0.1:80;

 server 192.168.0.2:80;



 check interval=3000 rise=2 fall=5 timeout=1000;



 #check interval=3000 rise=2 fall=5 timeout=1000 type=ssl_hello;



 #check interval=3000 rise=2 fall=5 timeout=1000 type=http;

 #check_http_send "GET / HTTP/1.0\r\n\r\n";

 #check_http_expect_alive http_2xx http_3xx;

}

server {

 listen 8888;

 proxy_pass cluster;

}

}