负载均衡是一个针对很多节点的分布式负载。
在网络行业，它通常作为一个web前端而被用来平衡各个server的http流量。为了这篇文章，我们关注Zenus负载均衡器在http和https流量上的负载均衡。
负载均衡器同意用户智能的分发流量到很多使用不同协议的多台server中的单个IP。这意味这负载处理能够被多个节点共享。而不是局限于在活动频繁时提高行单个server性能。这提高了你的web应用的可靠性，并且同意你为自己的应用创建冗余节点。假设server中一个节点失败，那么这些流量将以可编程的方式分发给其它节点而不用中断服务。
为什么及什么时候使用负载均衡
本质上，负载均衡解决的是超过一个节点的问题。
你能够使用负载均衡来保证你的站点在流量高峰期或者随着你的站点越来越受欢迎时能保持正常执行。
使用负载均衡最常见的两种场景：
限制故障点 (故障转移)
通过限制有效故障点。可提高网站正常执行时间。
假设你在两个或两个以上同样的节点之间做负载均衡，当集群中不论什么一个节点发生硬件或者软件故障时。流量就会被分配到其它节点以保证你的网站能够正常执行。付过你很关心正常执行时间。在两个同样的节点之间做负载均衡能够使各个节点单独处理你的网站流量。这同意当中一个失败的情况下能够不用停用网站。
负载分配 流量增长超出了单台server的承受能力
随着你的站点越来越受欢迎，站点的流量将超出你最好的server的承受能力，并且须要比单台server更强大的配置。升级单台server，对双server规模（一台webserver，一台数据库server）来说这仅仅同意有限的负载增长。之后要做的事情就是通过负载均衡将多台server组织起来。
负载均衡方法
Zeus提供了很多方法来实现负载均衡。
每种方法都有优缺点。
轮询调度（Round Robin）
使用轮询来实现负载均衡的话，负载均衡器将顺序性的将流量调度到每一个节点。
这样的方法均匀的分配流量。可是并不考虑节点的当前负载和响应能力。
最小连接调度（Least Connect）
这样的方法会考虑当前server和负载均衡器之间打开的连接数，负载均衡器分配流量到活跃连接数最少的server。这样的方法更智能，可是还是没有考虑当前节点的负载和响应能力。
历史智能或感知算法（Historical Intelligence or the Perceptive Algorithm）
这样的方式通过计算负载均衡器和每台server之间打开的连接数以及每一个节点的响应时间双方面来决定将流量分配到哪个节点。这中方法最大的不同是，Zenus会逐渐将流量分配到server池中新增的server上。这样的方式下假设你想高速提高站点的负载能力可能是个问题，可是当你有server发生问题时这样的方式对故障server所承担的流量处理非常有优点。
选择最合适的方式
对大多数网站来说最受欢迎的负载均衡方式是历史智能或感知算法。
这样的选择唯一不适用的情况是假设你的网站在处理和内存方面很轻量级，并且所保存的历史数据已经超过了你的网站需求。Liguid web提供有Zeus和思科负载均衡都有支持，可供用户选择，你能够选择最适合你的负载均衡方式。
1. 本文由程序猿学架构翻译
2. 本文译自Understanding Load Balancing | Liquid Web Knowledge Base
3. 转载请务必注明本文出自：程序猿学架构(微信号：archleaner )
4. 很多其它文章请扫码：
版权声明：本文博客原创文章，博客，未经同意，不得转载。