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

原文  http://blog.csdn.net/ESoftWind/archive/2006/10/19/1341120.aspx

 

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 ，备份的频率和备份对象的粒度将严重影响性能。