负载均衡方案总结

所有的例子都通过访问www.ctrip.com为例。这里只讲方案，具体的NGIX、LVS、HAPROXY怎么工作的等以后细看了再总结。

HTTP重定向负载均衡

 

用户通过域名解析， 得到IP地址114.100.80.100，访问这台服务器，这台机器收到请求之后，因为它是知道服务器集群里的IP的， 然后返回一个重定向到114.100.80.1的请求给用户的浏览器，然后浏览器再访问114.100.80.1。

这个方案致命的缺点就是经过了两次请求，因为建立HTTP连接的请求的代价是很大的，所以现在采用这种方案的很少。

 

 

DNS域名解析负载均衡

用户在访问www.ctrip.com的时候，在运营商的域名解析服务器里会对应多个IP。然后用户在访问的时候，只需要直接访问某一个IP就可以了。

这种方案看起来很不错，没有多次请求，跟没有集群，访问当个应用服务器的效果是一样的。

但是这个方案如果单独使用的话，肯定是不行的，因为更新域名解析服务器里的IP和域名的对应关系，是有延迟的。比如某台机器挂掉了或者需要发布，要被拉出集群，但是如果用这种方案，用户还是会访问到这个IP，这肯定是不行的。

 

 

反向代理负载均衡

这种方案的典型代表就是Ngix，将用户的请求在内网里做一次转发。而Ngix是工作在应用层的，是一个第七层的协议。需要将包解析，然后转发给web服务器。因此同样的访问量的情况下，方向代理的吞吐量是远不如IP负载均衡的。

 

 

 

IP 负载均衡

相对于反向代理负载均衡，IP负载均衡直接作用于TCP/IP层，工作在第四层。

用户请求来了之后，修改请求报文头里的目的地址，然后转发给服务器集群，不再做一次解包封包的过程。典型的方案是linux里的LVS模块，中国人写的哦，相信大家应该都听说过他的名字——章文嵩。现在貌似已经是淘宝的副总了。

这种方案看起来已经很不错了，但是其缺点是负载均衡的带宽问题。每次服务器返回都会经过IP负载均衡服务器。如果一个页面有2M的大小，这样的方案其实扛不住多少并发。

 

数据链路层负载均衡

那么最后，终极方案来了：数据链路层负载均衡。

这个方案，在第2层，这种数据传输方式又称为三角传输，负载均衡数据分发过程中不修改IP地址，只修改目的MAC地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址交换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称之为直接路由方式（DR）.

这个一般由交换机或者路由器来完成。

 

 

总结下最佳方案，也是现在使用比较广泛的方案：DNS负载均衡+数据链路层负载均衡

 

负载均衡的算法

轮询

略

加权轮询

略

随机

最简单，最实用，也是用的最多的算法。

最少链接

略

源地址散列

就是根据用户的IP地址，做一次hash然后算到某个IP。这个的好处就是同一个用户每次都能算到同一个IP。但是，虽然能够实现会话粘滞，我觉得却并没有什么卵用，比如发布的时候，总是算到这台机器，那就悲剧了。所以一般不会用这种算法。