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

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

 

数据库备份方式

几乎所有的 J2EE 集群产品都允许选择将你的会话对象通过 JDBC 备份到关系数据库中。如图 7 所示，这种方式可以让服务器实例非常简单的在正确的时间序列化会话内容并写到数据库中。当发生会话转移时，另一台可用的服务器接过已失效的服务器工作，从数据库中恢复所有的会话状态。序列化对象是关键点，它使得内存会话数据可以持久化和传输。要了解更多有关 Java 对象序列化知识，请参考 http://java.sun.com/j2se/1.5.0/docs/guide/serialization/index.html 。

 

图 7   备份会话数据到数据库

由于数据库交易是非常昂贵的，这种方法主要缺点是当在会话中保存大量的或大的对象时限制了伸缩性，大多数使用数据库会话持久化的服务器产品都提倡尽量减少用 HTTP 会话存储对象，但这限制了你的应用程序的架构和设计，特别是你要使用 HTTP 会话缓存用户数据时。

数据库的方式也有一些优点：

l      简单，容易实现。分离的请求处理和会话备份处理使集群更好管理和健壮。

l      会话可以失效转移到任何一台服务器，因为数据库是共享的。

l      当整个集群失效时，会话数据依旧幸免。

内存复制方式

因为性能的原因，一些 J2EE 服务器（ Tomcat ， Jboss ， WebLogic ， WebSphere ）提供了另一种实现：内存复制

 

图 8   对会话状态进行内存复制

基于内存的会话持久化将会话信息保存在一台或是多台备份服务器中，而不是保存数据库中（如图 8 ）。这种方式因为性能高而非常流行。同数据库方式相比，直接在原服务器和备份服务器之间网络通信是非常轻量的。同时注意在使用方式中，数据库方式中的“恢复”阶段是不需要的，因为在备份后，所有会话数据都已经存在备份服务器的内存中了，已经可以处理请求。

“ Java Groups ”是当前 Tomcat 和 Jboss 集群所使用的通信层。 Java Groups 是用于实现可靠组通信和管理的工具包。它提供了诸如“组成员协议”和“消息广播”等核心特性，这些都对集群的工作非常有用。有关 Java Groups 的信息，请参考： http://www.jgroups.org/javagroupsnew/docs/index.html 。

Tomcat 方式：多服务器复制

内存复制也存在许多不同的方式，第一种方法就是将会话数据复制到集群中的所有结点， Tomcat5 采用的就是这种方式。

 

图 9   多服务器复制

如图 9 所 示，当一个服务器实例的会话改变后，将备份到其他所有的服务器上。当一台服务器失效后，负载均衡器可以选择其他任何一台可用的服务器实例。但这种方式限制 了伸缩性，如果集群中有很多的服务器实例，那么网络通信的代价就不能被忽略，这将严重降低性能，并且网络也将成为系统的瓶颈。

WebLogic ， Jboss 和 Websphere 的方式：对等服务器复制

由于性能和伸缩性的原因， WebLogic ， Jboss 和 Webshpere 采用了其他方式实现内存复制。每台服务器任意选择一台服务器备份其内存中的会话信息。如图 10 所示。

在这种方式中，每台服务器都有一台自己的对等服务器，而不是其他所有的服务器，这种方式消除在集群中加入过多服务器实例的话影响伸缩性的问题。

 

图 10   对等服务器复制

尽管这种方式实现失效转移有很高的性能和伸缩性，但它仍有一些限制：

l      它给负载均衡器带来了更多的复杂性。当一台服务失效后，负载均衡器必须知道那台服务是这台己失效服务器的对等备份服务器。这将缩小了负载均衡器的选择范围，同时有些硬件也不能满足这种要求。

l      除了处理正常的请求外，服务器还将负责复制的任务。由于备份会话数据的任务也需要占用 CPU 的周期，所以每台服务器的请求处理能力也降低了。

l      在没有发生失效转移的时候，备份服务器上大量用于备份的内存是个浪费。同时这也将增加了 JVM GC 的负担。

l      集群中的服务器实例构成了复制对。这样，当会话所在主服务器失效后，负载均衡器将会话转移到备份服务器，使备份服务器处理两倍的请求，这将造成备份服务器的性能问题。

为了克服上面的 4 点问题，不同的软件供应商采用了不同的方法， WebLogic 采用的复制对不是对每台服务器，而是对每个会话。当一台服务器实例失效后，会话数据己经分散备份到多个备份服务器上，使失效的负载均匀地分布。

IBM 的方式：中央状态服务器

Websphere 采用不同的方式实现内存复制：备份会话信息到中央的状态服务器，如图 11 所示：

 

图 11   中央状态服务器复制

这与数据库的解决方案非常类似，不同之处在于专用的“会话备份服务器”代替了数据库服务器，这种方式结合了数据库和内存复制两种方式的优点。

l      将请求处理和会话备份处理分开使用集群更加健壮。

l      所有的会话数据都备份到专用的服务器上，无需服务器浪费内存用于备份其他服务器的会话。

l      因为会话备份服务器是在服务器之间共享的，所有失效后可以转移到任何一台服务器上，这样大多数据软硬件负载均衡器都可以使用，更重要的是当一台服务器失效后，负载将均匀的分布到所有实例上。

l      与重量级的数据库连接相比，应用服务器与备份服务器之间 Socket 通信是轻量的。这样就比数据库的解决方案有更好的性能和更好的伸缩性。

然而，由于有恢复失效服务器会话数据的这么一个阶段，因此其性能肯定不如两台服务器直接复制解决方案，另外，多出来一台备份服务器也增加了管理的复杂性。也可能由于单台备份服务器造成性能瓶颈。

Sun 的方式：特殊数据库

 

图 12   特殊数据库复制

Sun JES 应用服务器采用了别的方式实现会话失效转移，如图 12 所示，它看上去很像数据库的方式，因为它采用关系数据库存储会话并通过 JDBC 访问所有会话数据。但是 JES 内部所使用的关系数据库称为 HADB ，已经为访问会话做了特别优化，并且将几乎所有的会话数据存在内存中。这样，你可以说它更像中央状态服务器的方式。