JBOSS的集群策略分析

来源：yesky 作者：罗小虎出处：巧巧读书 2006-03-10 进入讨论组

服务器结点拓扑图的刷新

　　JBOSS的集群实现是动态的，也就是说你可以动态地往集群中加入一个新节点或关闭任意一个节点，而不用费力地维护一张静态的拓扑图，就好像是JBOSS自己有能力管理集群一样。这个思想够先进吧？但与此同时它也带来了一些令人头痛的问题，请先看下图：

　　由于JBOSS的集群策略是在客户端进行的，那么客户端在调用EJB的时候会将所有必须的组件下载下来，然后由其进行集群决策。如果我们设T为时间，且t0＜t1＜t2，那么当处于t0时刻时，集群拓扑图中包含server1和server2两个节点，客户端的调用被转发到了结点2上。当处于t1时刻时，server1和server2全部都崩溃了。当处于t2时刻时，管理员增加了server3和server4两个节点，但客户端的拓扑图中还只是包含原先的server1和server2两节点的信息，因为它无法知道这新加入的2个节点。

　　为了解决这个问题，JBOSS是这样设计的，在客户端的每次对某个节点调用后，服务器节点自动检查客户的拓扑图是不是最新的，如果不是，则向客户端发送新的拓扑图，如下图所示：

　　当客户端进行调用时，代理对像对其进行了一个小小的包装，它将系统级调用invocation和自已现在的拓扑图（JBOSS开发者称它为view ID）发送到服务端，而服务端则检查它自己的view ID是否与代理对像中的view ID吻合。这里我们先简单介绍一下view ID，它实际上就是包含所有服务器节点的一个哈希表，至于为什么要用哈希表是因为它生成方便（java编译器自带）、存取快速，无须考虑排序问题。

　　下面接着讲述，如果代理对像的view ID与服务端节点的view ID相吻合的话，服务端将直接把结果传给EJB对像，并将结果返回。

　　如果服务器集群拓扑产生了变化，则会导致它们不吻合。这时服务器节点同样也将调用EJB对像，但此时返回的结果有所不同，它除了返回客户端的结果外，还要为代理对像返回一个最新的view ID，并通知代理对像："喂，你的拓扑图太旧了，我发了份新的，你赶快更新一下吧！"　当代理对像收到这个消息后会更新自己的view ID，并将结果返回客户端代码。

　　性能考虑

　　对于JBOSS来说，实现负载平衡与失效转发所带来的性能上的损失是很难计算的，因为它只发生在客户端上，而每个客户端不管从硬件配置、操作系统来说都是不一样的。

　　由于本文讲的主要是对于无状态的EJB对像的集群，但如果是有状态的EJB或实体EJB，那情况会怎样呢？答案是：情况只会更糟！为此服务器节点不得不进行状态复制，而这个开销通常是很大的，取决于状态中上下文的内容和状态更新的频率。所幸的是，对于大多数应用而言，它们主要是进行无状态的EJB调用，这样就不服务器节点就不需进行大量状态复制了。

　　结论

　　JBOSS为J2EE应用提供了一个非常灵活有效的集群机制。它能使得在保持服务端性能损失最小的情况下进行失效转发，并能动态地对集群节点进行配置。更令人振奋的是，在JBOSS4.0中，集群机制将会发挥到极致，到时候就不仅仅是J2EE应用能够进行集群管理了，连普通的J2SE应用都能进行集群了，到那时高可用性的计算并不只是一句口号了，而是JBOSS的一个简单实现！

http://www.qqread.com/java/w502767600.html