Java EE集群技术初探——第四部分(各大厂商的产品如何Web层集群)

 

“JavaGroups” 是目前 JBoss 和 Tomcat 集群使用的通信层。 JavaGroups 是一套可靠的组合通信和管理工具包。其中的核心功能，如 “ 组员协议 ” 与 “ 消息多播 ” 技术，是支持集群正常工作的重要基础。具体内容可以参考 http://www.jgroups.org/javagroupsnew/docs/index.html 。

 

Tomcat ：多服务器复制

有很多种内存复制的办法，第一种就是将会话数据复制到集群中的所有节点上。 Tomcat 5 就是使用者中方法实现的。

在上图中，当一个特定服务器实例的会话改变时，它将数据备份到所有其他服务器上。当该服务器实例失败后，负载均衡器能选择其他可用的服务器实例进行接管。但此方法在可扩展性上存在一定局限。如果集群中的实例数量较多，就不能忽略网络通信的额外开销，可能严重影响网络通信性能并成为应用性能的瓶颈。

 

WebLogic 、 JBoss 、 WebSphere ：服务器配对复制

考虑到性能和可扩展性的因素， WebLogic 、 JBoss 和 WebSphere 都使用了另一种内存复制的技术：每个服务器实例选择另一专门的备份实例来存储会话信息，如下图：

使用这种方法，每个服务器实例都有与其匹配的备份服务器。本方法在更多实例被添加到集群中时消除了可扩展性的问题。

 

虽然本方法也能实现高性能的会话失败转移和高可扩展性，但其依然具有以下局限性：

• 增加了负载均衡器的复杂度。当服务器实例失败时，负载均衡器需要找出该服务器的匹配备份服务器。这就影响到负载均衡器的选择范围，在这样的要求下一些硬件负载均衡器就不能使用了。
• 除了正常处理请求外，服务器还需要承担复制的工作。这可能影响到服务器的吞吐量，因为需要将一些CPU时钟周期分配用来做复制的工作。
• 在正常的处理过程中(没有失败转移法生的情况下)，备份服务器中存储的备份会话信息浪费了大量的服务器内存，这会对JVM的GC(垃圾回收) 产生额外的开销。
• 由于集群中的服务器是配对复制的，所以当主服务器上失败后，负载均衡器就将该对服务器的所有请求转移到配对的备份服务器上。备份服务器于是就会处理很多额外的请求，可能造成备份服务器性能问题。

 

为了克服上述问题，各厂商都纷纷出招。 WebLogic 为了克服最后一个问题，将复制配对定义从服务器粒度上降低到会话粒度上。当一个服务器实例失败后，其上的会话被分散转移至备份服务器中，并将均衡失败后的负载分配。

 

IBM ：集中状态服务器

WebSphere 有另外一种方案来进行内存复制：将所有会话信息集中备份到一台状态服务器 ( 我记得 Sybase 在其第一个 J2EE 服务器产品 EAServer 或 Jaguar CTS 中就采用本方法实现集群，目前最新的版本是 6 ，不知道有没有改变 ) ，如下图：

 

该方案和数据库持久化的方案很像。不同点在于本方法指定一台 “ 会话备份服务器 ” 来代替数据库。这种方案结合了数据库持久化方案和内存复制方法的优点：

• 将请求处理和会话备份处理分离，这样能让集群更健壮。
• 所有会话数据将被备份到一台特定的服务器上，不需要其他服务器浪费内存空间存储会话数据。
• 由于会话备份服务器是集群中所有节点都共享的，所以会话的失败转移可顺利完成。所以，可在集群中使用大多数软硬件负载均衡器，更为重要的是，服务器实例失败时，其请求负载将被均衡分散。
• 和数据库连接比较，应用服务器和会话备份服务器之间的网络通信更为轻量，所有比数据库持久化方案具有更好的可扩展性和性能。

 

但是，由于需要对失败服务器的会话数据进行恢复，其性能不如直接配对内存复制方案的优越。同时，单独的会话备份服务器也增加了管理的难度，也可能由于备份服务器单一的原因造成性能影响。在会话备份服务器宕机的情况下，集群就不能进行正常工作。

 

SUN ：特定数据库方案

SUN JES 应用服务器如上图所示，采用不同的方式实现会话失败转移。从表面上看，这种方法和数据库持久化方法一样，他们都采用了一个关系型数据库通过 JDBC 连接来存储和访问所有会话数据。但是从内部来看， JES 使用的是 HADB ，其是专门被优化用来存储访问会话数据的，并将大部分数据都存储在内存中。所以，可能更与集中式状态服务器的解决方案接近。

Java EE集群技术参考文档下载http://www.betteryou.com.cn/downloads/docs.jsp