WEB服务器流量超负载:如何分散解决?

不支持服务器间的一致性。服务器一致性是负载均衡系统所应具备的一种能力，通过它，系统可以根据会话信息是属于服务器端的，还是底层数据库级别的，继而将用户的请求导向相应的服务器。而DNS轮流排程则不具备这种智能化的特性。它是通过cookie、隐藏域、重写URL三种方法中的一种来进行相似的判断的。当用户通过上述基于文本标志的方法与服务器建立连接之后，其所有的后续访问均是连接到同一个服务器上。问题是，服务器的IP是被浏览器暂时存放在缓存中，一旦记录过期，则需要重新建立连接，那么同一个用户的请求很可能被不同的服务器进行处理，则先前的所有会话信息便会丢失。

　　不支持高可靠性。设想一个具有N个节点的集群。如果其中的一个节点毁坏，那么所有的访问该节点的请求将不会有所回应，这是任何人都不愿意看到的。比较先进的路由器可以通过每隔一定的时间间隔，对节点检查，如果有毁坏的节点，则将之从列表中去除的方法，解决这个问题。但是，由于在Internet上，ISPs将众多的DNS存放在缓存中，以节省访问时间，因此，DNS的更新就会变得非常缓慢，以至于有的用户可能会访问一些已经不存在的站点，或者一些新的站点得不到访问。所以，尽管DNS轮流排程在一定程度上解决了负载均衡问题，但这种状况的改变并不是十分乐观和有效的。

　　除了上面介绍的轮流排程方法外，还有三种DNS负载均衡处理分配方法，将这四种方法列出如下：

　　Round robin (RRS)： 将工作平均的分配到服务器 (用于实际服务主机性能一致)

　　Least-connections (LCS)： 向较少连接的服务器分配较多的工作(IPVS 表存储了所有的活动的连接。用于实际服务主机性能一致。)

　　Weighted round robin (WRRS)： 向较大容量的服务器分配较多的工作。可以根据负载信息动态的向上或向下调整。 (用于实际服务主机性能不一致时)

　　Weighted least-connections (WLC)： 考虑它们的容量向较少连接的服务器分配较多的工作。容量通过用户指定的砝码来说明，可以根据装载信息动态的向上或向下调整。(用于实际服务主机性能不一致时)

　　三：传统负载均衡器的优势及缺点

　　负载均衡器通过虚拟IP地址方法，解决了轮流排程所面临的许多问题。使用了负载均衡器集群系统，在外部看来，像是具有一个IP地址的单一服务器一样，当然，这个IP地址是虚拟的，它映射了集群中的每一台机器的地址。所以，在某种程度上，负载均衡器是将整个集群的IP地址报漏给外部网络。

　　当请求到达负载均衡器时，它会重写该请求的头文件，并将之指定到集群中的机器上。如果某台机器被从集群中移除了，请求不会别发往已经不存在的服务器上，因为所有的机器表面上都具有同一个IP地址，即使集群中的某个节点被移除了，该地址也不会发生变化。而且，internet上缓存的DNS条目也不再是问题了。当返回一个应答时，客户端看到的只是从负载均衡器上所返回的结果。也就是说，客户端操作的对象是负载均衡器，对于其更后端的操作，对客户端来讲，是完全透明的。

　　传统负载均衡器的优点

　　服务器一致性. 负载均衡器读取客户端发出的每一个请求中所包含的cookies或url解释。基于所读出的这些信息，负载均衡器就可以重写报头并将请求发往集群中合适的节点上，该节点维护着相应客户端请求的会话信息。在HTTP通信中，负载均衡器可以提供服务器一致性，但并不是通过一个安全的途径（例如：HTTPS）来提供这种服务。当消息被加密后（SSL），负载均衡器就不能读出隐藏在其中的会话信息。

　　通过故障恢复机制获得高可靠性. 故障恢复发生在当集群中某个节点不能处理请求，需将请求重新导向到其他节点时。主要有两种故障恢复：

　　请求级故障恢复。当集群中的一个节点不能处理请求时（通常是由于down机），请求被发送到其他节点。当然，在导向到其他节点的同时，保存在原节点上的会话信息将会丢失。

　　透明会话故障恢复。当一个引用失败后，负载均衡器会将之发送到集群中其他的节点上，以完成操作，这一点对用户来说是透明的。由于透明会话故障恢复需要节点具备相应的操作信息，因此为了实现该功能，集群中的所有节点必须具有公共存储区域或通用数据库，存储会话信息数据，以提供每个节点在进行单独进程会话故障恢复时所需要的操作信息。

　　统计计量。既然所有的Web应用请求都必须经过负载均衡系统，那么系统就可以确定活动会话的数量，在任何实例访问中的活动会话的数目，应答的次数，高峰负载次数，以及在高峰期和低谷期的会话的数目，还有其他更多的。所有的这些统计信息都可以被很好的用来调整整个系统的性能。

　　传统负载均衡器的缺点

　　硬件路由的缺点在于费用、复杂性以及单点失败的。由于所有的请求均是通过一个单一的硬件负载均衡器来传递，因此，负载均衡器上的任何故障都将导致整个站点的崩溃。

　　HTTPS请求的负载均衡

　　正如上面所提到的，很难在那些来自HTTPS的请求上进行负载均衡和会话信息维护处理。因为，这些请求中的信息已经被加密了。负载均衡器没有能力处理这类请求。不过，这里有两种方法可以解决这一问题：

　　代理网络服务器

　　硬件SSL解码器

　　代理服务器位于服务器集群之前，首先由它接受所有的请求并对之进行解密，然后将这些处理后的请求根据头信息重新发往相应的节点上，这种方式不需要硬件上的支持，但会增加代理服务器的额外的负担。

　　硬件SSL解码器，则是在请求到达负载均衡器之前，先经由它进行解密处理。这种方式比代理服务器的处理速度要快捷一些。但代价也高，而且实现比较复杂。