负载均衡

DNS轮循（或DNS的循环机制），是指一种负载分发，负载均衡或者容错性地提供多个冗余的IP服务主机的技术。

当前，负载均衡器有各种各样的工作排程演算法（用于决定将前端用户请求发送到哪一个后台服务器），最简单的是随机选择和轮询。更为高级的负载均衡器会考虑其它更多的相关因素，如后台服务器的负载，响应时间，运行状态，活动连接数，地理位置，处理能力，或最近分配的流量。

高性能系统通常会使用多层负载均衡。另外专用的硬件负载均衡器以及纯软件负载均衡器，包括开源的，例如Apache Web服务器的mod proxy balancer扩展，nginx，Varnish和Pound反向代理和负载均衡器。使用Gearman将合适的计算任务分发给多台计算机，如此大量的任务就可以更快的完成了。

对于一个多层次架构体系，在负载均衡器或网络分发器后面有两种设计，术语称之为Bowties和Stovepipes。Stovepipe设计中，事务是从顶部分发的，然后从一个固定通道通过一系列硬件和软件设备，到达最终目的地。如果使用Bowties设计，在每一层中事务处理有多条路径可供选择。在事务处理的网络结构中可能会是Stovepipes，也可以是Bowties，或者根据每一层的实际需求采用杂货构架。

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

理想下，在负载均衡后面的服务器集群（Server cluster）不应该保存会话（session-aware），如此一来，一个用户不管什么时候连接任何一个后端服务器都不会收到影响。常用的方案是通过一个磁盘数据库（传统数据库）或者一个内存数据库（如： Memcached），实例可参考：Django 缓存框架。[2] 将会话信息存到磁盘数据库的这个方案由于会增加数据库的负载，所以这个方案对性能的提高并不好。磁盘数据库最好是用来存储会话时间比较长的会话数据。

为了避免数据库出现单点故障，并且提高其扩展性，数据库通常会复制到多台服务器上，通过负载均衡器来分发请求到数据库服务器上。微软ASP.NET中的状态服务器技术就是一个典型的会话数据库的例子。集群中的所有服务器都将它们的会话信息保存到状态服务器上，同时它们可以向状态服务器查询会话数据。

另一个简单的解决方案是，将一个指定的用户的的今后的所有请求都会发送到同一个后台服务器——这种方案也被称为“粘性（sticky）会话”或者“持续化（persistence）”。但该方案的不足之处在于：无法容错(故障轉移)，假如后台服务器故障，该用户的所有的会话的访问，自然地会话本身也将丢失。即便是数据库服务器也发生该情况。虽然Web服务（Web Service）不存在状态和粘性（sticky），但是用户和数据库存是绑定的（存在粘性）。

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

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

不论是软件负载均衡器，还是硬件负载均衡器都有一系列的特性：

• 不对称负载调节。可以对后台服务器设置权重因子，权重因子用于控制服务器的请求处理量，进而控制服务器的负载。当后台服务器的处理能力不是等同的时候，这是一种控制服务器负载的简单方法。
• 优先啟動。当出现故障的服务器达到某个阈值，或者服务器负载过高时，备用服务器必需可以及时上线提供服务。
• SSL截断和加速。依赖服务器负载，处理加密数据或者通过SSL进行的授权请求会消耗Web服务器的大量CPU，随着需求增加用户会明显感觉到响应时间变长。为了消除Web服务器上这部分（处理加密）负载，负载均衡器可能会将SSL通讯截断在负载均衡器上。有些硬件负载均衡器上包含有专门用于处理SSL的硬件。当负载均衡器截断SSL连接请求，再将用户请求转发给后台前将HTTPS变为HTTP。只要负载均衡器不超载，这个特性不会影响用户体验。这种方法的负面效应是，由于所有SSL都由负载均衡器一台设备来处理，它会导致负载均衡器成为负载均衡体系的一个瓶颈。如果不使用这个特性，SSL请求将会分发给各个Web服务器处理。是否采用这一特性，需要分析比较两者的资金投入情况，含有处理SSL特殊硬件的负载均衡器通常价格高昂，而Web服务器一般比较廉价。增加少量的Web服务器的花费可能明显比升级负载均衡器要少。另外，一些服务器厂商如Oracle/Sun也开始在它们的CPU中加入加密加速模块，例如T2000。在负载均衡器上截断SSL的另一个优点是允许负载均衡器可以对基于HTTPS请求数据进行负载均衡或内容交换。
• DDOS攻击防护。负载均衡器可以提供例如SYN cookies特性和延时绑定（在TCP握手完成之前，后台服务器不会与用户通讯）来减缓SYN flood攻击，并且通常将工作从服务器分载到更有效的平台。
• HTTP压缩。使用gzip和Deflate等算法压缩HTTP数据，以减少网络上的数据传输量。对于响应时间较长，传输距离较远的用户，这一特性对于缩短响应时间效果明显。这个特性会耗费负载均衡器更多的CPU，这一功能也可以由Web服务器来完成。
• TCP offload。不同的厂商叫法可能不一样。其主要思想是一样的，通常每个用户的每个请求都会使用一个不同的TCP连接，这个特性利用HTTP/1.1将来自多个用户的多个请求合并为单个TCP socket再转发给后台服务器。
• TCP缓冲。负载均衡器可以暫存后台服务器对客户的响应数据，再将它们转发给那些响应时间较长网速较慢的客户，如此后台Web服务器就可以释放相应的线程去处理其它任务如直接整个响应数据直接发送给网速较快的用户。
• 后台服务器直接响应用户（Direct Server Return）。这是不对称负载分布的一项功能，在不对称负载分布中请求和回应通过不同的网络路径。
• （服务器）健康检查。负载均衡器可以检查后台服务器应用层的健康状况并从服务器池中移除那些出现故障的服务器。
• HTTP缓存。负载均衡器可以存储静态内容，当用户请求它们时可以直接响应用户而不必再向后台服务器请求。
• 内容过滤。有些负载均衡器可以按要求修改通过它的数据。
• HTTP安全。有些负载均衡器可以隐藏HTTP出错页面，删除HTTP响应头中的服务器标示信息，加密cookies以防止用户修改。
• 优先队列。也可称之为流量控制。它可以对不同的内容设定不同的优先级。
• 内容感知开关（Content-aware switching）。大多数负载均衡器可以基于用户请求的URL发送请求到不同的后台服务器，无论内容是加密（HTTPS）还是没有加密（HTTP）。
• 用户授权。对来自不同身份验证源的用户进行验证，然后再允许他们访问一个网站。
• 可编程的流量控制。不只一种负载均衡器允许使用脚本编程来定制负载均衡方法、任意的流量控制以及其它功能。
• 防火墙功能。由于安全的原因，不允许用户直接访问后台服务器。防火墙是由一系列规则构成，它们决定着哪些请求可以通过一个接口而哪些不被允许。
• 入侵阻止功能。在防火墙保障网络层/传输层安全的基础上，提供应用层安全防范。