揭开J2EE集群的神秘面纱（二）

WEB层集群实现

WEB层集群是J2EE集群的重要且基本的功能。WEB集群技术包括WEB负载均衡和HTTP Session失效转移。

WEB负载均衡

J2EE提供商实现WEB负载均衡有许多方式。基本上，都一个负载均衡器被插入到浏览器和WEB服务器之间，如下图所示。

图 5  WEB负载均衡

负载均衡器可以是一台硬件，如F5负载均衡器，或仅仅是另一台有负载均衡Plug-Ins的WEB服务器，一个简单的带ipchains的Linux box可以很好的实现负载均衡。不管采用哪种技术，负载均衡器都有以下特性：

l     实现负载均衡算法

当客户请求到来时，负载均衡器需要决定将如何分发到后台服务器。流行的算法是Round-Robin、Random和Weight Based。负载均衡器尽力使每台服务器实例都获得相同的负载，但是上述算法没有一个可以获得理想的负载相同，因为它们仅仅是依据发送到特定服务器的请求的个数。一些精密的负载均衡器实现了特殊的算法。它在分发请求之前将检测服务器的工作负载。

l     健康检测

当一台服务器失效了，负载均衡器应当检测出失效并不再将请求分发到这台服务器上。同样，它也要检测服务器是否恢复正常，并恢复分发请求。

l     会话胶粘

几乎所有的WEB应用程序都有一些会话状态，可能是简单的记住用户是否登陆，或是包含你的购物车信息。因为HTTP本身是无状态的，会话状态应当存在服务器的某个地方并与你当前浏览会话相关联，这样当你下次再请求相同WEB应用程序的页面时可以很容易的重新获取。当负载均衡时，最佳的选择就是将特定的浏览器会话分发到上次相同的服务器实例中，否则，应用程序可能不能正确工作。

因为会话状态存储在特定WEB服务器的内存中，“会话胶粘”对于负荷均衡非常重要。但是，如果其中某台服务器实例因为某种原因失效了（比如关机），那么这台服务器的会话状态将要丢失。负载均衡器应当检测到这个失效并不再将请求分发给它，但这些请求的会话状态都因为存放在失效的服务器中而丢失了所有信息，这就将导致错误。会话的失效转移因此而生。

HTTP Session失效转移

几乎所有流行的J2EE供应商都在他们的集群产品中实现了Http Session失效转移，用来保障当某台服务器失效后会话状态不会丢失，使客户端请求能被正确处理。如图6所示，当浏览器访问有状态的WEB应用程序（第1 ,2步），这个应用程序可能在内存创建了会话对象用于保存信息以供后面的请求使用，同时，发送给浏览器一个唯一的HTTP Session ID用于标识这个会话对象（第3步），浏览器将这个ID保存Cookie中，并当它下次再请求同一WEB应用程序的页面时，会将Cookie发还给服务器。为了支持会话失效转移，WEB服务器将在一定的时候把会话对象备份到其他地方以防止服务器失效后丢失会话信息（第4步）。负载均衡器检测到这个失败（第5，6步），并将后续的请求分发到装有相同应用程序的服务器实例中（第7步），由于会话对象已经备份到其他地方了，这个新的服务器实例可以恢复会话（第8步）正确地处理请求。

图 6  HTTP Session失效转移

为了实现上述功能，HTTP Session失效转移将带来以下问题：

l     全局HTTP Session ID

如上所述，HTTP Session ID用于在特定的服务器实例中标识唯一的内存会话对象，在J2EE平台，HTTP Session ID依赖于JVM实例，每个JVM实例拥有几个应用程序，每个应用程序都为不同的用户管着许多会话，HTTP Session ID是在当前JVM实例用于访问相关会话的关键。在会话失效转移的实现中，要求不同的JVM实例不能产生两个相同的HTTP Session ID，这是因为当失效转移发生时，一个JVM的会话将要备份并恢复到另一个中，这样，必须建立全局HTTP Session ID产生机制。

l     如何备份会话状态

如何备份会话状态是区别J2EE服务器好坏的关键因素。不同的供应商有不同的实现，在后续部分我再详细解释。

l     备份的频率和粒度

会话的备份是消耗性能的，包括CPU，内存，网络带宽和写入磁盘和数据库的I/O，备份的频率和备份对象的粒度将严重影响性能。

转载自：http://blog.csdn.net/esoftwind/article/details/1341120