JNDI集群
Jndi集群对于EJB也是非常重要的，因为几乎所有的EJB都是从JNDI调用开始的
共享全局JNDI树
Weblogic和JBOSS都使用一个全局的、共享的、分布在整个集群系统的JNDI树，对象被绑定到全局上下文，使用ip多播方式拷贝JNDI数据
图十四：全局共享JNDI
集群中的每个节点都有自己的命名服务器，并且自动保存其他所有节点的JNDI数据，因此这种结构具有高度可靠性
实际中，集群JNDI树主要有两个用途：一是用于部署，你只需要将某个EJB部署到一台服务器上，系统会自动将其拷贝到其他节点。二是在运行中你可以用JNDI存取自己的对象，这些自定义对象同样会被自动拷贝到其他节点。
独立的JNDI树
Sun JES, IBM Websphere和其他厂商使用的是独立的JNDI树，各个节点拥有自己独立的JNDI，而不会关心其他节点的JNDI。但这并不意味着它们不能实现集群，关键是每台服务器上的配置要相同，应用也要相同，这样的话通过代理agent就能实现高性能的集群了
Sun JES 和 IBM Websphere都在每个节点处安装了一个agent，由console负责协调各个agent
但这种方式不支持动态绑定运行时生成的对象，设计者的理由是：JNDI本身就是作为管理外部资源的中间层，运行时对象绑定不在JNDI的职责范围内，如果真的有这种需要，可以使用LDAP或者具有HA功能的数据库。Sun和IBM都有自己的LDAP实现
中央型JNDI树
少数厂商采用中央型的JNDI，所有节点都去一个某个指定的JNDI服务器上获取资源，当然这对于客户端来说是透明的。不过这种方式会大大增加安装和管理的复杂性，因此被大部分厂商放弃
怎样开始连接JNDI呢
使用JNDI，你必须知道提供JNDI服务的域名或IP以及端口，在全局和独立型JNDI树中，都存在着多个JNDI服务器，客户端要连接哪一个呢，负载均衡和失效备援又是如何实现的呢？
技术上来说，可以在客户端和JNDI服务器之间放一个硬件或软件实现的负载均衡器，来实现上述要求，不过大部分厂商都有更加简单的方法：
lSUN JES 和JBOSS 能够令“java.naming.provider.url”这一JNDI属性支持用逗号分隔多个地址，例如，“java.naming.provider.url=server1:1100,server2:1100,server3:1100,server4:1100”，客户端会逐个搜索，直到找到一个可用的为止
lJBOSS还支持自动找寻功能，即令“java.naming.provider.url”属性为空，客户端会自动以网络多播的方式寻找一个JNDI服务器作为查询的起始点
EJB集群原理
EJB衍生自分布式计算技术，服务器组件或富客户端都能够以标准协议（RMI/IIOP）调用远程的EJB，并且RMI/IIOP技术能够屏蔽底层网络，使得EJB的调用对客户透明化
图：EJB调用原理
如图，客户端不是直接和EJB打交道，而是通过stub来代理。Stub负责利用RMI找到远程的EJB并进行调用。EJB的调用过程分为下面三步（EJB2.0）
l从JNDI中查找EJBHOME stub
l利用home stub创建一个EJB Object stub
l利用EJB Object stub调用EJB的方法
在JNDI查找时，可以利用上文说到的方法进行负载均衡；各厂商也会有自己专门的技术对stub的使用进行负载均衡，一般有以下三种方式：
Smart stub
我们知道，stub可以通过JNDI来获得和创建，甚至可以直接下载相应的class文件来在运行时动态生成，而无须在客户端本地的classpath中声明
图十七：smart stub
如图十七，Weblogic 和JBOSS通过在stub的代码中嵌入特殊的代码来实现集群，这个stub的确相当smart，它包含了所有能够访问的集群服务器节点、内置了专门的集群算法来决定把请求发给何处，甚至当集群的拓扑有变时（比如增加了节点），能动态改变自身来适应新的结构，无须手工干预
Smart stub有以下几个好处：
l节省大量服务器资源
l由于负载均衡是由客户端处理，因此可以防止在服务器端放置负载均衡器而可能导致的单点失败
lStub可以动态下载安装，意味着无须手工维护
IIOP Runtime Library
Sun JES采用另一种方法，它直接修改客户端的IIOP运行时库
图十八：IIOP Runtime
如图十八，sun直接把负载均衡逻辑转移到了IIOP库中，从而使stub能够保持“小而轻”，同时由于IIOP是底层库，能够更加有效地获取和使用JVM提供的资源。但正是由于底层库有所不同，使得JES与其他J2EE服务器打交道时可能会出现一些问题
Interceptor Proxy
IBM Websphere使用Location Service Daemon (LSD)作为一个拦截器代理来实现EJB集群
Figure 19: Interceptor Proxy
使用这种机制，stub中包含至LSD的路由信息，而不是直接去找服务器节点，这样LSD就能获得所有请求并进行负载均衡了，不过这样会大大增加管理和维护的成本
EJB的集群支持
调用EJB方法的过程中我们要和两个stub打交道，一个是home stub，另一个是object stub，因此可以在两个层面上实现负载均衡和失效备援
EJBHOME STUB的集群实现
由于EJBHOME STUB本身不包括任何客户端信息，无论从哪个服务器上获得的EJBHOME STUB都是一样的，因此当客户端调用EJBHOME STUB的create等方法时，就能利用一些负载均衡的算法选择合适的服务器节点
EJBOBJECT STUB的集群实现
EJBOBJECT STUB包含业务接口，而且其本身也能够含有集群节点的信息，但也不是所有的方法调用都能够进行负载均衡式的路由，得看EJB的类型是什么
l无状态会话bean最容易实现负载均衡了，因为它本身不包含特定的客户信息
l有状态会话bean略有不同，因为它本身包含客户端的会话信息，因此有状态bean的集群实现本质上和HTTP session 无异，一般情况下客户端的stub都是一直与某个节点上的EJB组件打交道的，除非中途出问题了才会将请求转发到备用的节点上
l实体bean本质上也是无状态的。表面上看可以采用和无状态会话bean一样的方式集群，但实际上很少厂商会对实体bean做集群。因为实体bean一般都是被其他会话bean调用的，因此通常都使用本地接口通讯，实在没有集群的必要
JMS和数据库连接的集群
目前一些数据库产品已经可以集群了，你可以部署成多份，每个节点之间可以同步。但是JDBC本质上是有状态连接，和底层的socket紧密绑定。当某个JDBC连接突然中断了，与之相关的对象也就费了，因此很难对JDBC集群。Weblogic使用一种JDBC multipool，可以在JDBC断开情况下，方便地进行重新连接
JMS的负载均衡和失效备援只在JMS broker上有实现，很少有厂商在JMS destination 的消息上实现了负载均衡
J2EE集群的困惑
失效备援能够防止所有错误吗？——错！
JBOSS的文档花了整整一章的内容来提醒你：“你真的需要HTTP SESSION复制吗”，有时候不用失效备援也能以经济的方式获得高可靠性。更何况，失效备援并没有你想象中的那么可靠
你也许认为失效备援能够在节点宕机时保护你的session数据，但你得清楚，这种保障是有条件的
回想一下作者在定义“失效备援”时，前提条件是“在两个方法调用之间”！也就是说只有在第一个方法成功返回之后、第二个方法调用开始之前，失效备援才能起作用
假设某个方法处理到一半时服务器不幸挂掉了，客户端一般只能收到错误消息。除非你这个方法恰好是“idempotent”的（即多次调用的结果都能保持一致，不会对环境造成任何改变，比如getter方法），那么有些聪明的负载均衡器会尝试找其他节点去调用这个方法
所以说“idempotent”这个概念非常重要，因为客户端压根不知道是在什么地方失败的，而如果这个方法不是idempotent，那么系统就可能处于一种不一致的状态，很危险
你也许认为事务性的方法就是idempotent的，毕竟事务可以回滚。但其实事务远远不能涵盖整个远程调用的范围，比如服务器成功执行某事务性方法后，返回结果的过程中网络崩溃了呢？
在比较严格的系统设计中，你根本不能令所有方法都idempotent，你能做的就是利用failover，尽可能减少错误而不是彻底杜绝错误。以某个网上商城为例：每台服务器都同时处理100个用户请求，当某台服务器崩溃时，如果没有失效备援，那么你会得罪一百个用户；而如果有失效备援，可能只有不到20个用户会发飙。你自己要权衡：
l是得罪一百个客户还是得罪20个客户？
l有没有失效备援的服务器的价格差别
独立的应用程序可以无缝地迁移到分布式平台上？——错！
这只是某些厂商的广告而已，不可轻信。如果是大型系统，那么设计之初就应该全盘考虑集群可能造成的影响
HTTP SESSION
正如前文所述，HTTP SESSION的集群会受到你使用的服务器的诸多限制。首先是可序列化的要求，在很多MVC架构中，session被用来存储一些不可序列化的对象（比如servlet context）；其次，序列化、特别是数据库方式的序列化非常耗费资源，因此要集群就尽量不要用session存储大对象。如果是内存拷贝的方式，那么就要考虑内存的限制和交叉引用的问题（交叉引用请参考前文）；最后，你在集群环境下改变session的属性时，必须使用“setAttribute”方法，而在单机环境下却没这个限制。这么做的主要原因是让你的应用服务器能够检测到属性改变，及时地备份已修改的属性
缓存
大部分流行的应用服务器都会使用缓存来提升性能，但缓存一般都是为单机环境设计的。集群环境下如果使用缓存，那么缓存之间的拷贝花费的性能将比缓存带来的好处还多，适得其反
静态变量
有一种很流行的J2EE设计模式“singleton（单体）”，是使用静态变量的，这在单机环境下适用，但到了集群就不行了，道理很简单，每个JVM都有自己的静态对象，“单体”也就失去意义了。比如要统计在线用户数时，经常用一个静态变量来存储，但是在集群环境下这种方法显然失去作用。要使用静态对象，最好把它放到一个数据库中，才能实现全局的“单体”
外部资源
尽管J2EE规范并不推荐，但外部IO操作还是有用的，比如用来存放用户上传的文件。在集群中，服务器是不能通过另一台服务器把本地文件直接存放到别的机器上的，那么还是要依靠数据库来统一存放文件，或者你可以使用SAN这种集中式文件仓库
专有服务
有些专有服务是只限于单机环境的，比如定时器服务（timer）；再比如某些事件触发类型的服务，如初始化服务，邮件提醒服务也属于此列。这些服务一般针对一个特定条件只发生一次，拿去集群没什么意义。JBOSS的“clustered singleton facility”就是用来保证所有服务器运行且只运行一次某种服务
分布式系统比并列式系统更灵活？——未必
尽管EJB生来就是为了分布式、解耦合，但很多框架认为把EJB层和web层放在一起也未尝不是好事，或许更好
图20：分布式架构
如图20，负载均衡器先将请求分发到适当服务器的web层，web层进一步判断调用何处的EJB，这等于是做了两次的负载均衡和失效备援。很多人认为这种设计并不好：
l首先，第二次的转发根本没有必要，每个服务器都有自己的web和ejb层，比起只调用内部的ejb，web层调用其他ejb层没有任何的好处
l第二次的失效备援也是没有必要的，大部分厂商都把web容器和ejb容器实现为在同一个jvm上跑，那样一旦web容器挂了，ejb容器很难独善其身
l损失性能，这个不必解释了，大量的服务器之间的调用对性能肯定有影响。
实际上，大部分厂商都让web容器优先选择同一个服务器上的ejb容器，这种方式称作“并列式”，是分布式的一种特例，如下图
图21：并列式
这样引出一个有趣的问题：既然都放一块了，为什么不直接用ejb的本地接口呢？虽然本地接口可以提高性能，但它却把web和ejb紧耦合在一起了，负载均衡机制也就没有办法对其进行优化，特别是当你要变成分布式的时候
此外很不幸的是，在集群环境下本地接口的使用经常受到限制，因为有本地接口的ejb通常是不可序列化的。所以有些应用服务器，比如sun JES，对本地接口的ejb做了特殊处理使其可以被序列化，从而保存到诸如session中去
还有一个问题是，既然大部分情况下并列式的性能都比较好，那还要分布式干什么呢？其实在某些情况下还非得用分布式不可：
l除了web容器，富客户端也要调用ejb组件
lWeb容器和ejb容器所处的安全级别不同，它们物流上也被放在不同的地方，中间加上一个防火墙
lEjb和web层的极度不对称。指的是复杂度的不对称，比如ejb层有大规模的运算，那就放在一台高级的服务器上，而web容器只需放在一台pc上即可
结论
集群与单机环境是有很大不同的，各厂商的集群实现也不同。最好在项目开始就考虑到集群，使得你的系统更有扩展性，根据自身的需求选择最合适的应用服务器，并且选购第三方软件时也要考虑到对集群的支持。最后，合适的架构可以让你受益于集群而不是让集群成为你的噩梦。
引用地址：http://blog.csdn.net/wangchengsi/article/details/2161132
原文出自 http://www.theserverside.com/tt/articles/article.tss?l=J2EEClustering