协议支持 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;}
}
