名词解释： 负载均衡load balance

负载均衡（Load balancing）是一种计算机网络技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。

使用带有负载均衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性(HA)。负载均衡服务通常是由专用软件和硬件来完成。

基于互联网的服务
负载均衡最重要的一个应用是利用多台服务器提供单一服务，这种方案有时也称之为server farm。通常，负载均衡主要应用于Web网站，大型的Internet Relay Chat网络，高流量的文件下载网站，NNTP（Network News Transfer Protocol）服务和DNS服务。现在负载均衡器也开始支持数据库服务，称之为数据库负载均衡器。

对于互联网服务，负载均衡器通常是一个软件程序，这个程序侦听一个外部端口，互联网用户可以通过这个端口来访问服务，而作为负载均衡器的软体会将用户的请求转发给后台内网服务器，内网服务器将请求的响应返回给负载均衡器，负载均衡器再将响应发送到用户，这样就向互联网用户隐藏了内网结构，阻止了用户直接访问后台（内网）服务器，使得服务器更加安全，可以阻止对核心网络栈和运行在其它端口服务的攻击。

当所有后台服务器出现故障时，有些负载均衡器会提供一些特殊的功能来处理这种情况。例如转发请求到一个备用的负载均衡器、显示一条关于服务中断的消息等。负载均衡器使得IT团队可以显著提高容错能力。它可以自动提供大量的容量以处理任何应用程序流量的增加或减少。

架构
高性能系统通常会使用多层负载均衡。另外专用的硬件负载均衡器以及纯软件负载均衡器，包括开源的，例如Apache Web服务器的mod proxy balancer扩展，nginx，Varnish和Pound反向代理和负载均衡器。使用Gearman将合适的计算任务分发给多台计算机，如此大量的任务就可以更快的完成了。
对于一个多层次架构体系，在负载均衡器或网络分发器后面有两种设计，术语称之为Bowties和Stovepipes。Stovepipe设计中，事务是从顶部分发的，然后从一个固定通道通过一系列硬件和软件设备，到达最终目的地。如果使用Bowties设计，在每一层中事务处理有多条路径可供选择。在事务处理的网络结构中可能会是Stovepipes，也可以是Bowties，或者根据每一层的实际需求采用杂货构架。

持续性【会话共享】
负载均衡器需要处理的一个重要问题是：如何保存用户会话？如果会话信息保存在后台服务器，用户接下来的请求可能会被分配到不同的后台服务器，此时用户会话就无法继续。负载均衡器可以缓存用户会话，然后将用户请求分发到不同的后台服务器。但是这将带来负载均衡器的负载问题。

一个解决方案是将一个用户会话中的所有请求都发送到同一个后台服务器。即persistence或stickiness。这个方法的不足之处在于无法容错failover,如果后台服务器故障，它提供的会话就会无法取得，任何依赖于它的会话都会丢失。这个问题通常与数据中心有关，尽管Web Service是非连结导向的，但是后端的数据库先天上还是连结导向的。

第二个方案是依据用户名，客户端IP来分配提供服务的服务器，也可以随机分配。因为客户可能是通过DHCP，NAT或者Web代理来连接Internet的，其IP地址可能经常变换，这使得这个方案的服务质量无法保障。随机分配由负载均衡器将会话信息存储保存。如果负载均衡器被替换或故障，这些信息可能会丢失；另外（负载均衡器）负载较高的时候，为保证分配表空间不会被耗尽，超时的分配信息必须被删除。随机分配方法也要求客户会维持会话状态，如果客户浏览器禁用了cookies的功能，就会引起问题。优秀的负载均衡器会使用多种持续（会话保持）技术，以避免其中某些不可以用时引起故障。

另外一个方案是将每一会话信息保存到一个数据库中。由于这个方案会增加数据库的负载，所以这个方案对性能的提高并不好。数据库最好是用来存储会话时间比较长的会话数据。为了避免数据库出现单点故障，并且提高其扩展性，数据库通常会复制到多台服务器上，通过负载均衡器来分发请求到数据库服务器上。微软ASP.net中的状态服务器技术就是一个典型的会话数据库的例子。集群中的所有服务器都将它们的会话信息保存到状态服务器上，同时它们可以向状态服务器查询会话数据。

幸运的是有一种更有效的方法，通常客户浏览器可以保存用户的每个会话信息。例如使用浏览器cookie，对数据加密并加上一个时间戳就可以保证安全了；URL重写。将会话信息存储在客户端通常是首选方案，因为这样负载均衡器就可以灵活的选择后台服务器来处理用户请求。然而这种方法不适应于一些较复杂的电子商务，因为电子商务中会话数据较大，而且需要服务器需要经常重新处理会话信息；与此同时URL重写由于用户可以改变会话流数据而存在安全问题；加密客户端cookies也一直存在着安全方面的争议，除非所有的会话都通过HTTPS，但是HTTPS很容易遭到中间人攻击。

与故障转移的关系
负载均衡对通讯链路的冗余是非常有用的。例如，一家公司可能有多条互联网接入线路以保证某一条故障时仍可以正常接入互联网。
故障转移的架构意味着一条连接正常使用，另外一条连接作为备用，当第一条出现故障时才会被启用。

使用负载均衡器，两条（多条）连接可以都投入使用。有一个设备或者程序实时监控着所有连接的连通性，并且对正在发送的包进行选路。同时使用多条连接可以增加带宽。
许多电信公司在其内部网络或连接到外部网络（其它电信网络）都有多条线路可以使用。为避免某条链路出现网络堵塞，最小化连接其它网络的费用或者提高网络的可靠性，它们使用负载均衡将流量从一条链路转移到另一条链路。
负载均衡经常被用于实现故障转移-当一个或多个组件出现故障时能持续提供服务这些组件都在持续监控（例如：Web服务器通过请求一个已知页面来监控是否正常工作）中，当一个组件没有响应，负载均衡器就会发现并不再向其发送数据。同样当一个组件重新上线，负载均衡器会重新开始向其发送数据。为了能够如前所述正常工作，负载均衡体系中至少要有一个冗余服务。采用一用一备方案（一个组件提供服务，一个备用，当主组件故障时备用组件将接管继续提供服务）比故障转移方案更加经济，灵活。有些类型的RAID系统使用的热备份功能跟这是类似的作用。