简介几种负载均衡原理

开头先理解一下所谓的“均衡”

不能狭义地理解为分配给全部实际服务器同样多的工做量，由于多台服务器的承载能力各不相同，这可能体如今硬件配置、网络带宽的差别，也可能由于某台服务器身兼多职，咱们所说的“均衡”，也就是但愿全部服务器都不要过载，而且可以最大程序地发挥做用。

1、http重定向

当http代理（好比浏览器）向web服务器请求某个URL后，web服务器能够经过http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理须要继续请求这个新的URL，完成自动跳转。

 

性能缺陷：

一、吞吐率限制

主站点服务器的吞吐率平均分配到了被转移的服务器。现假设使用RR（Round Robin）调度策略，子服务器的最大吞吐率为1000reqs/s，那么主服务器的吞吐率要达到3000reqs/s才能彻底发挥三台子服务器的做用，那么若是有100台子服务器，那么主服务器的吞吐率可想而知得有大？相反，若是主服务的最大吞吐率为6000reqs/s，那么平均分配到子服务器的吞吐率为2000reqs/s，而现子服务器的最大吞吐率为1000reqs/s，所以就得增长子服务器的数量，增长到6个才能知足。

二、重定向访问深度不一样

有的重定向一个静态页面，有的重定向相比复杂的动态页面，那么实际服务器的负载差别是不可预料的，而主站服务器却一无所知。所以整站使用重定向方法作负载均衡不太好。

咱们须要权衡转移请求的开销和处理实际请求的开销，前者相对于后者越小，那么重定向的意义就越大，例以下载。你能够去不少镜像下载网站试下，会发现基本下载都使用了Location作了重定向。

2、DNS负载均衡

DNS负责提供域名解析服务，当访问某个站点时，实际上首先须要经过该站点域名的DNS服务器来获取域名指向的IP地址，在这一过程当中，DNS服务器完成了域名到IP地址的映射，一样，这样映射也能够是一对多的，这时候，DNS服务器便充当了负载均衡调度器，它就像http重定向转换策略同样，将用户的请求分散到多台服务器上，可是它的实现机制彻底不一样。

相比http重定向，基于DNS的负载均衡彻底节省了所谓的主站点，或者说DNS服务器已经充当了主站点的职能。但不一样的是，做为调度器，DNS服务器自己的性能几乎不用担忧。由于DNS记录能够被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过时后才会从新向域名的DNS服务器请求解析。也说是DNS不存在http的吞吐率限制，理论上能够无限增长实际服务器的数量。

特性:

一、能够根据用户IP来进行智能解析。DNS服务器能够在全部可用的A记录中寻找离用记最近的一台服务器。

二、动态DNS：在每次IP地址变动时，及时更新DNS服务器。固然，由于缓存，必定的延迟不可避免。

不足：

一、没有用户能直接看到DNS解析到了哪一台实际服务器，加服务器运维人员的调试带来了不便。

二、策略的局限性。例如你没法将HTTP请求的上下文引入到调度策略中，而在前面介绍的基于HTTP重定向的负载均衡系统中，调度器工做在HTTP层面，它能够充分理解HTTP请求后根据站点的应用逻辑来设计调度策略，好比根据请求不一样的URL来进行合理的过滤和转移。

三、若是要根据实际服务器的实时负载差别来调整调度策略，这须要DNS服务器在每次解析操做时分析各服务器的健康状态，对于DNS服务器来讲，这种自定义开发存在较高的门槛，更况且大多数站点只是使用第三方DNS服务。

四、DNS记录缓存，各级节点的DNS服务器不一样程序的缓存会让你晕头转向。

五、基于以上几点，DNS服务器并不能很好地完成工做量均衡分配，最后，是否选择基于DNS的负载均衡方式彻底取决于你的须要。

 

3、反向代理负载均衡

这个确定你们都有所接触，由于几乎全部主流的Web服务器都热衷于支持基于反向代理的负载均衡。它的核心工做就是转发HTTP请求。

 

相比前面的HTTP重定向和DNS解析，反向代理的调度器扮演的是用户和实际服务器中间人的角色：

一、任何对于实际服务器的HTTP请求都必须通过调度器

二、调度器必须等待实际服务器的HTTP响应，并将它反馈给用户（前两种方式不须要通过调度反馈，是实际服务器直接发送给用户）

 

特性：

一、调度策略丰富。例如能够为不一样的实际服务器设置不一样的权重，以达到能者多劳的效果。

二、对反向代理服务器的并发处理能力要求高，由于它工做在HTTP层面。

三、反向代理服务器进行转发操做自己是须要必定开销的，好比建立线程、与后端服务器创建TCP链接、接收后端服务器返回的处理结果、分析HTTP头部信息、用户空间和内核空间的频繁切换等，虽然这部分时间并不长，可是当后端服务器处理请求的时间很是短时，转发的开销就显得尤其突出。例如请求静态文件，更适合使用前面介绍的基于DNS的负载均衡方式。

四、反向代理服务器能够监控后端服务器，好比系统负载、响应时间、是否可用、TCP链接数、流量等，从而根据这些数据调整负载均衡的策略。

五、反射代理服务器可让用户在一次会话周期内的全部请求始终转发到一台特定的后端服务器（粘滞会话），这样的好处一是保持session的本地访问，二是防止后端服务器的动态内存缓存的资源浪费。

 

4、IP负载均衡(LVS-NAT)

 

由于反向代理服务器工做在HTTP层，其自己的开销就已经严重制约了可扩展性，从而也限制了它的性能极限。那可否在HTTP层面如下实现负载均衡呢？

NAT服务器:它工做在传输层，它能够修改发送来的IP数据包，将数据包的目标地址修改成实际服务器地址。

从Linux2.4内核开始，其内置的Neftilter模块在内核中维护着一些数据包过滤表，这些表包含了用于控制数据包过滤的规则。可喜的是，Linux提供了iptables来对过滤表进行插入、修改和删除等操做。更加使人振奋的是，Linux2.6.x内核中内置了IPVS模块，它的工做性质类型于Netfilter模块，不过它更专一于实现IP负载均衡。

IPVS的管理工具是ipvsadm，它为提供了基于命令行的配置界面，能够经过它快速实现负载均衡系统。这就是大名鼎鼎的LVS(Linux Virtual Server，Linux虚拟服务器)。

一、打开调度器的数据包转发选项

echo 1 > /proc/sys/net/ipv4/ip_forward

二、检查实际服务器是否已经将NAT服务器做为本身的默认网关，若是不是，如添加

route add default gw xx.xx.xx.xx

三、使用ipvsadm配置

ipvsadm -A -t 111.11.11.11:80 -s rr

添加一台虚拟服务器，-t 后面是服务器的外网ip和端口，-s rr是指采用简单轮询的RR调度策略（这属于静态调度策略，除此以外，LVS还提供了系列的动态调度策略，好比最小链接（LC）、带权重的最小链接（WLC），最短时间望时间延迟（SED）等）

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m

添加两台实际服务器（不须要有外网ip），-r后面是实际服务器的内网ip和端口，-m表示采用NAT方式来转发数据包

运行ipvsadm -L -n能够查看实际服务器的状态。这样就大功告成了。

实验证实使用基于NAT的负载均衡系统。做为调度器的NAT服务器能够将吞吐率提高到一个新的高度，几乎是反向代理服务器的两倍以上，这大多归功于在内核中进行请求转发的较低开销。可是一旦请求的内容过大时，不管是基于反向代理仍是NAT，负载均衡的总体吞吐量都差距不大，这说明对于一睦开销较大的内容，使用简单的反向代理来搭建负载均衡系统是值考虑的。

这么强大的系统仍是有它的瓶颈，那就是NAT服务器的网络带宽，包括内部网络和外部网络。固然若是你不差钱，能够去花钱去购买千兆交换机或万兆交换机，甚至负载均衡硬件设备，但若是你是个屌丝，咋办？

 

一个简单有效的办法就是将基于NAT的集群和前面的DNS混合使用，好比５个100Mbps出口宽带的集群，而后经过DNS来将用户请求均衡地指向这些集群，同时，你还能够利用DNS智能解析实现地域就近访问。这样的配置对于大多数业务是足够了，可是对于提供下载或视频等服务的大规模站点，NAT服务器仍是不够出色。

5、直接路由(LVS-DR)

NAT是工做在网络分层模型的传输层（第四层），而直接路由是工做在数据链路层（第二层），貌似更屌些。它经过修改数据包的目标MAC地址（没有修改目标IP），将数据包转发到实际服务器上，不一样的是，实际服务器的响应数据包将直接发送给客户羰，而不通过调度器。

一、网络设置

这里假设一台负载均衡调度器，两台实际服务器，购买三个外网ip，一台机一个，三台机的默认网关须要相同，最后再设置一样的ip别名，这里假设别名为10.10.120.193。这样一来，将经过10.10.120.193这个IP别名来访问调度器，你能够将站点的域名指向这个IP别名。

二、将ip别名添加到回环接口lo上

这是为了让实际服务器不要去寻找其余拥有这个IP别名的服务器，在实际服务器中运行：

另外还要防止实际服务器响应来自网络中针对IP别名的ARP广播，为此还要执行：

echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "1" > /proc/sys/net/ipv4/conf/all/arp_announce

配置完了就可使用ipvsadm配置LVS-DR集群了

ipvsadm -A -t 10.10.120.193:80 -s rr

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g

-g 就意味着使用直接路由的方式转发数据包

LVS-DR 相较于LVS-NAT的最大优点在于LVS-DR不受调度器宽带的限制，例如假设三台服务器在WAN交换机出口宽带都限制为10Mbps，只要对于链接调度器和两台实际服务器的LAN交换机没有限速，那么，使用LVS-DR理论上能够达到20Mbps的最大出口宽带，由于它的实际服务器的响应数据包能够不通过调度器而直接发往用户端啊，因此它与调度器的出口宽带没有关系，只能自身的有关系。而若是使用LVS-NAT，集群只能最大使用10Mbps的宽带。因此，越是响应数据包远远超过请求数据包的服务，就越应该下降调度器转移请求的开销，也就越能提升总体的扩展能力，最终也就越依赖于WAN出口宽带。

总的来讲，LVS-DR适合搭建可扩展的负载均衡系统，不管是Web服务器仍是文件服务器，以及视频服务器，它都拥有出色的性能。前提是你必须为实际器购买一系列的合法IP地址。

6、IP隧道(LVS-TUN)

基于IP隧道的请求转发机制：将调度器收到的IP数据包封装在一个新的IP数据包中，转交给实际服务器，而后实际服务器的响应数据包能够直接到达用户端。目前Linux大多支持，能够用LVS来实现，称为LVS-TUN，与LVS-DR不一样的是，实际服务器能够和调度器不在同一个WANt网段，调度器经过IP隧道技术来转发请求到实际服务器，因此实际服务器也必须拥有合法的IP地址。

整体来讲，LVS-DR和LVS-TUN都适合响应和请求不对称的Web服务器，如何从它们中作出选择，取决于你的网络部署须要，由于LVS-TUN能够将实际服务器根据须要部署在不一样的地域，而且根据就近访问的原则来转移请求，因此有相似这种需求的，就应该选择LVS-TUN。

 

本文属于原创，若有疑问请后台留言，若有转载请标注原做者，版权归本公众号全部。若是你喜欢我写的文章请关注微信公众号 全栈开发者社区，欢迎你们继续关注本公众号的技术博文。若是您以为本文章对你有所帮助的话，不妨点个赞，您的支持就是我坚持原创的动力。