昨天去面试一家致力于开源社区的公司，做系统架构师。被问到几个问题，是作为企业大型架构经常会遇到问题，第一：企业负载平衡架构应该如何搭建；第二：如何来保证高可用性（即多台服务器集群时，当一台服务器宕机后，另一台服务器能支持使用）；第三；分布式缓存如何实现。在以前虽然有涉及到，但是未深入了解，下面就负载均衡的方案查询相关资料，做一个整理。
1、什么是负载均衡
负载均衡主要实现下面四点：
第一，网络负载均衡能将传入的请求传播到多达32台服务器上，即可以使用最多32台服务器共同分担对外的网络请求服务。网络负载均衡技术保证即使是在负载很重的情况下，服务器也能做出快速响应;
第二，网络负载均衡对外只需提供一个IP地址(或域名);
第三，当网络负载均衡中的一台或几台服务器不可用时，服务不会中断。网络负载均衡自动检测到服务器不可用时，能够迅速在剩余的服务器中重新指派客户机通讯。这项保护措施能够帮助你为关键的业务程序提供不中断的服务，并可以根据网络访问量的增加来相应地增加网络负载均衡服务器的数量;
第四，网络负载均衡可在普通的计算机上实现
2、负载均衡的算法
平衡算法设计的好坏直接决定了集群在负载均衡上的表现，设计不好的算法，会导致集群的负载失衡。一般的平衡算法主要任务是决定如何选择下一个集群节点，然后将新的服务请求转发给它。有些简单平衡方法可以独立使用，有些必须和其它简单或高级方法组合使用。而一个好的负载均衡算法也并不是万能的，它一般只在某些特殊的应用环境下才能发挥最大效用。因此在考察负载均衡算法的同时，也要注意算法本身的适用面，并在采取集群部署的时候根据集群自身的特点进行综合考虑，把不同的算法和技术结合起来使用。
l 轮转法：轮转算法是所有调度算法中最简单也最容易实现的一种方法。在一个任务队列里，队列的每个成员（节点）都具有相同的地位，轮转法简单的在这组成员中顺序轮转选择。在负载平衡环境中，均衡器将新的请求轮流发给节点队列中的下一节点，如此连续、周而复始，每个集群的节点都在相等的地位下被轮流选择。这个算法在DNS域名轮询中被广泛使用。轮转法的活动是可预知的，每个节点被选择的机会是1/N，因此很容易计算出节点的负载分布。轮转法典型的适用于集群中所有节点的处理能力和性能均相同的情况，在实际应用中，一般将它与其他简单方法联合使用时比较有效。
l 散列法： 散列法也叫哈希法（HASH），通过单射不可逆的HASH函数，按照某种规则将网络请求发往集群节点。哈希法在其他几类平衡算法不是很有效时会显示出特别的威力。例如，在前面提到的UDP会话的情况下，由于轮转法和其他几类基于连接信息的算法，无法识别出会话的起止标记，会引起应用混乱。而采取基于数据包源地址的哈希映射可以在一定程度上解决这个问题：将具有相同源地址的数据包发给同一服务器节点，这使得基于高层会话的事务可以以适当的方式运行。相对称的是，基于目的地址的哈希调度算法可以用在Web Cache集群中，指向同一个目标站点的访问请求都被负载平衡器发送到同一个Cache服务节点上，以避免页面缺失而带来的更新Cache问题。
l 最少连接法：在最少连接法中，平衡器纪录目前所有活跃连接，把下一个新的请求发给当前含有最少连接数的节点。这种算法针对TCP连接进行，但由于不同应用对系统资源的消耗可能差异很大，而连接数无法反映出真实的应用负载，因此在使用重型Web服务器作为集群节点服务时（例如Apache服务器），该算法在平衡负载的效果上要打个折扣。为了减少这个不利的影响，可以对每个节点设置最大的连接数上限（通过阈值设定体现）。
l 最低缺失法 ：在最低缺失法中，平衡器长期纪录到各节点的请求情况，把下个请求发给历史上处理请求最少的节点。与最少连接法不同的是，最低缺失记录过去的连接数而不是当前的连接数。
l 最快响应法：平衡器记录自身到每一个集群节点的网络响应时间，并将下一个到达的连接请求分配给响应时间最短的节点，这种方法要求使用ICMP包或基于UDP包的专用技术来主动探测各节点。在大多数基于LAN的集群中，最快响应算法工作的并不是很好，因为LAN中的ICMP包基本上都在10ms内完成回应，体现不出节点之间的差异；如果在WAN上进行平衡的话，响应时间对于用户就近选择服务器而言还是具有现实意义的；而且集群的拓扑越分散这种方法越能体现出效果来。这种方法是高级平衡基于拓扑结构重定向用到的主要方法。
另外还有加权算法等，这里就不再多介绍。
从总体上来说负载均衡的方案有硬件的解决方案和软件的解决方案，当然在硬件的解决方案针对网络在不同的层次提供响应的策略。
l 首先先说明硬件解决方案的优缺点：
首先是贵，这个贵不仅是体现在一台设备上，而且体现在冗余配置上．很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置，一旦出了问题就全趴了．补充说明常用的负载平衡的设备在20多W以上，当然如果用F5就更加贵了。
第二是对服务器及应用状态的掌握：硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）
补充第二点，从网络层判断按照策略有轮转法、散列法等，主要通过数据包的源地址分配到后台的应用。
硬件负载平衡方案实际上都是在网络协议层做请求的分发。它做的工作很简单，接受请求，根据策略进行分发。此外，它还承担故障切换的任务，当某个节点宕机以后，会将分发到这个节点的请求分发到其他节点(会定期进行心跳检测，确定节点工作与否)。当节点恢复正常以后，还可以继续把请求再分发过来。 同时这种负载均衡方案是针对网络协议级别的，它至多实现对端口和协议的控制，但是它对服务器上面运行了什么程序，有什么数据一无所知，所以硬件方式更适用于一大堆设备、大访问量、简单应用。
l 软件方式，其实也分多种情况，这里只讲一下典型的专业负载均衡软件。看了硬件方式的不足就比较容易理解专业负载均衡软件的优点了：
首先是基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的。像LVS，要求在各个参与负载均衡的服务器上面安装软件，而不是单独弄一台机器做这个事情(成本大幅度降低，同时也可以避免单点故障，不过效率要降低很多)。
其次价格便宜，如果只是几台服务器，而去购买F5就杀鸡用牛刀了。
软件在应用服务器的群集同样可以实现负载均衡和故障切换和恢复，只不过可靠性和效率要比硬件负载均衡器低很多罢了。
当然在实际工作中可能采用是混合式策略，前端采用硬件负载平衡，后端多台服务器采用应用服务器集群。
在设计负载均衡的方案时，要注意一下三点：
第一点：均衡调度策略，即采用的负载均衡的算法，这个在第二章里面已经做了介绍，不同的硬件和软件有不同的策略配置。
第二点：心跳检测。用于检查后台多台服务器的是否宕机，宕机后能将请求提交给其他正常的服务器。
第三点：持久化策略。会话的处理，在大多数的程序里，会使用到Session，那么在负载均衡的方案中如何实现，当然在网上也有很多建议，即会话放到分布式缓存或者数据库中，在负载均衡的方案中不考虑，但事实上硬件可直接用粘性会话方案解决
l Java
在Java领域在负载均衡可选的方案很多，根据不同的企业应用服务器，都相应提高集群功能，例用WebLogic的集群功能，Jboss等。
l 。Net
在Windows的应用中，可选的负载均衡的软件不是太多，例如，Microsoft® Network Load Balancing 是用于 Web 场的负载平衡软件，而 Microsoft Component Load Balancing 是用于应用程序场的负载平衡软件。
