关于在集群中编程的问题(zhuan)

关于在集群中编程的问题

注意以下几点：（目前只想到这些）
1、往session里边放的东东要实现序列化的接口（session复制用）
2、因为session要复制，所以session里边的东西要尽可能的少，否则可能集群性能还不如单机
3、集群下没有真正单例的实现，所以不要用单态模式来保存集群内所有服务器都需要的状态，比如程序的某个全局变量，可以考虑用jndi来实

现。不过相信好的程序这么做的并不多。
4、同步问题也要注意~比如不要试图用加同步来实现取得最大id这样的操作，可以通过保存到数据库的手段来解决这个问题
5.特别要注意缓存的情况，大部分开源的缓存实现是不支持集群的。这时候要全面考虑你需要的缓存情况再定夺。比较省事的办法是不用缓存

（缓存的作用不是任何时候都很大，比如客户查询话费祥单记录，越加缓存越坏事）。如果对数据实时性要求不算高那也好说，定期的重建缓

存就是了。如果都不行，只有使用jboss cache等支持集群的cache实现。或者采用某些商业性的实现。
------------------------
weblogic的分发是怎么实现的：
1、实现请求的分发，可以靠硬件（高层交换机），也可以靠weblogic自己。一般的是新建一个proxy分发域，然后其中部署一个proxy应用，利

用weblogic.servlet.proxy.HttpClusterServlet将请求分发到不同的server。
2、分发的过程是这样的（不管是交换机还是weblogic）:
数个请求发过来，先判断一下请求的ip地址，将ip地址相同的发送到同一台server,不同的ip根据分发策略分发到不同的server.
如果一台server不可用，请求将不会发送至这一台server.原本发送至这台不可用server的请求将被发送至此server session复制目的地

server.(到底是哪一台看相应的复制策略)。这样，客户端session也就不会失效，这一过程对客户是透明的。呵呵，不知道这样算不算是

failover
------------------------
Web只是EJb的一种客户端，RMI/XML-RPC/Web Service/Corba都是EJB企业应用服务器的客户端。
------------------------
Session Replication 绝对不是为负载平衡用的。绝大多数情况下，负载平衡器都有一个基本特性叫做“Session Affinity”。也就是说，同

一个SESSION，即使在负载平衡的情况下，也是由同一个节点来提供服务的。这是性能优化的必然要求。
这首先要从SESSION REPLICATION的机制说起来。SESSION 复制发生的时间顺讯可能有两种：1。每次请求都复制。2。定时复制。第一种情况可

以基本保障节点之间SESSION状态在绝大多数情况下是同步的，但是这样做的潜在性能代价非常高。
以上说明，从应用层面上看，“任何时间主从节点状态都同步”的要求是基本上不可能达到的。直接逻辑结论就是，主服务节点的重新导向不

能在任意时间发生。这就是为什么要有SESSION AFFINITY。
AFFINITY在系统软件是一个普遍应用的优化技术。多CPU操作系统，比如WINDOWS,UNIX,LINUX，相应地有“PROCESS AFFINITY,THREAD AFFINITY

”的概念，基本上出于同样的原理。CPU的L1 CACHE，在这里就对应于我们的SESSION STATE。为了不造成频繁的缓存冲洗，OS就要保证PROCESS

被绑定在一个CPU上。
SESSION AFFINITY实现的方式，取决于不同的应用服务器是不同的。软件负载平衡器一般是应用服务器的一个WEB SERVER插件。这个插件里就

内建了SESSION AFFINITY逻辑。硬件负载平衡器也支持SESSION AFFINITY，当然这需要一些配置。详见（http://e-

docs.bea.com/wls/docs81/cluster/load_balancing.html#1044135）
------------------------
综上，负载平衡在绝大多数情况下，只发生在建立SESSION之前。一旦SESSION建立，那么SESSION AFFINITY会保障同一SESSION绑定在一个节点

上。而SESSION REPLICATION的目的，是在发生FAIL-OVER的情况下，会话状态不会丢失，也就是BANQ说的“用户没有感觉”。

要对每次请求都做负载平衡，有两种选择：1。你完全不计较性能，通过配置保证每个请求都做状态复制。这不是每款应用服务器都支持的。这

方面没有什么JSR标准。2。你的应用完全是“应用服务器无会话状态”的。也就是说，所有的会话状态存在数据库或者客户端。这种架构并不

适用于所有的应用。商业企业应用大多数都有相当数量的会话状态和CONTEXT状态，采用数据库状态会带来频繁的数据库操作，而客户端状态首

先未必能够容纳那么多数据，即使能够容纳，每次请求都要附带大量状态数据，会对网络传输造成压力。
------------------------
1。所谓状态恢复，就是通过状态复制实现的。状态复制不一定要在两个节点之间。比如WEBSPHERE，就是把状态复制到数据库。在WEBSPHERE里

，状态复制有两种方式，通过内存复制（类似WEBLOGIC），或者通过数据库永久化。无论那种方式，对于应用而言都是透明的，目的都是在

FAIL-OVER情况下实现透明的状态恢复。

2。EJB的负载平衡，也不是所谓“时时刻刻都在发生”。EJB的负载平衡，同样有“SESSION AFFINITY”的优化，当然这是针对于SFSB。对于

SLSB而言，既然没有状态，和WEB负载平衡就不具备可比性。
EJB的负载平衡，不但在概念上，甚至在算法上，实现上，都和WEB集群完全一致。

并且，EJB的负载平衡和 WEB负载平衡相比，作用要小得多。这样说的原因：

第一：绝大多数生产环境里，EJB的客户端是WEB，并且EJB和WEB是共同部署。也就是说，如果EJB容器死了，那么WEB容器肯定也死了。EJB的负

载平衡逻辑是建入在STUB里的。既然WEB已经死了，那么STUB也就不存在了。谈何EJB负载平衡？

第二，LOCAL EJB是没有集群功能的。

第三，ENTITY EJB是没有集群功能的。

第四，在WEB,EJB共同部署的情况下，即使WEB访问EJB是通过REMOTE INTERFACE, 应用服务器也会做优化，把访问当作类似LOCAL INTERFACE的

方式处理（目的是为了省略不必要的对象序列化）。这样获得的STUB有目的地关闭了集群逻辑。原因在一中已经描述。

所以，EJB的集群，只在下面的情况下才会发生：
REMOTE SESSION BEAN（STATEFUL或者STATELESS）, 并且客户端不部署在同一JVM里。即使在这样的情况下，EJB开发者还要保证EJB方法是

IDEMPOTENT的。
EJB集群。WEB集群二者的实现，在代码层面都是用同样的代码，何来一者简陋另一者高级？
----------------------
1。从负载平衡的实现机制角度讲，没有人说WEB负载平衡算法只有ROUND ROBIN一种。基于CPU负载的平衡算法，也就是BANQ称作“EJB集群的智

能”，同样也适用于WEB负载平衡。这一点上EJB集群和WEB集群毫无区别。
BANQ所谓“EJB集群的智能”，有两个要求：CPU负荷检测，和请求重定向。这两个要求，WEB容器都可以轻松实现。有什么理由认为EJB容器可

以做到这些而WEB容器不能？请问BANQ，这两点中哪一点是WEB容器不可实现的？

2。从CPU负载分布模式看， BANQ描述的WEB集群情况下大负荷请求重复定向给同一节点的问题，同样也适用于EJB集群。BANQ描述的WEB负载分

配所可能出现的问题（大负荷请求重复发向同一节点），其根本假设是WEB请求的CPU负荷模式很不均匀。请问，同样的假设难道不适用于EJB?

难道EJB的CPU负荷模式莫名其妙地会比WEB请求更均匀？另外，这种情况，是计算机科学中负载平衡方面的经典病理情况，有多种方法解决。最

简单的就是所有服务器都支持的随机平衡算法。更重要的，随机平衡算法也是WEB和EJB集群都支持的算法。

负载平衡不是什么EJB独有的特殊算法。EJB负载平衡算法基本上都是计算机科学里大家耳熟能详的东西。EJB和WEB在负载平衡方面，无论机理

还是算法，都是一致的。BANQ似乎认为EJB集群的优势在于EJB集群能够根据CPU负荷进行重新负荷分配而WEB集群不具备这个功能。这是完全而

彻底的误解。

3。从生产环境的现实角度看，这种“基于CPU负荷重新分配负载”的行为，虽然实现起来并不难，却没有多少实用价值。理论分析，模拟数据

和生产实践都表明，ROUND ROBIN，RANDOM, 和根据负荷的“自适应反馈算法”，在性能方面没有很大区别。这是 相关数据在多数操作系统或

者计算机网络教科书里都有描述。这听起来似乎有些奇怪，但不过是“大数定理”的必然结果。

4。从现实商业服务器支持角度看：BANQ描述的“根据CPU重新分配负荷”的行为，至少在WEBLOGIC, WEBSPHERE两者都不支持。Weblogic和

WebSphere只支持 Round Robin, 加权 Round Robin和随机 这三种算法（Web集群和EJB集群都一样！）。 JBoss支持一种“First Available”

的算法，但实质上是随机算法。
当然，WebLogic允许用户自己开发和定制负载分配算法，但是未见有记录表明用户通过自定义负载分配算法提高了性能的。否则，IBM，BEA，

JBOSS会只支持这三种算法么？
并且，对于 WEBLOGIC 和 WEBSPHERE, 缺省状况下即使是 REMOTE EJB ， 在JNDI解析时也会被“本地优先”，根本不会做负载平衡。
再者，一旦会话建立，后续请求会由于“Session Affinity”优化而绑定在同一节点，也不会做负载平衡。
----------------
JNDI查询的是HOME INTERFACE STUB。FAILOVER逻辑，在WEBLOGIC和JBOSS上，是建入在智能REMOTE STUB里的，在WEBSPHERE上是建入在代理服

务器上，JES是建入在IIOP运行库里, 和JNDI都压根不搭界。
JNDI是不会根据集群运行状况而返回一个不同的STUB的。

EJB的最初设计思想是“地点透明”（SESSION BEAN，也可以说是分布计算吧），和关系数据对象化（ENTITY BEAN），根本不是由“集群”驱

动的。

1。从负载平衡的实现机制角度讲，没有人说WEB负载平衡算法只有ROUND ROBIN一种。基于CPU负载的平衡算法，也就是BANQ称作“EJB集群的智

能”，同样也适用于WEB负载平衡。这一点上EJB集群和WEB集群毫无区别。
BANQ所谓“EJB集群的智能”，有两个要求：CPU负荷检测，和请求重定向。这两个要求，WEB容器都可以轻松实现。有什么理由认为EJB容器可

以做到这些而WEB容器不能？请问BANQ，这两点中哪一点是WEB容器不可实现的？

2。从CPU负载分布模式看， BANQ描述的WEB集群情况下大负荷请求重复定向给同一节点的问题，同样也适用于EJB集群。BANQ描述的WEB负载分

配所可能出现的问题（大负荷请求重复发向同一节点），其根本假设是WEB请求的CPU负荷模式很不均匀。请问，同样的假设难道不适用于EJB?

难道EJB的CPU负荷模式莫名其妙地会比WEB请求更均匀？另外，这种情况，是计算机科学中负载平衡方面的经典病理情况，有多种方法解决。最

简单的就是所有服务器都支持的随机平衡算法。更重要的，随机平衡算法也是WEB和EJB集群都支持的算法。

负载平衡不是什么EJB独有的特殊算法。EJB负载平衡算法基本上都是计算机科学里大家耳熟能详的东西。EJB和WEB在负载平衡方面，无论机理

还是算法，都是一致的。BANQ似乎认为EJB集群的优势在于EJB集群能够根据CPU负荷进行重新负荷分配而WEB集群不具备这个功能。这是完全而

彻底的误解。

3。从生产环境的现实角度看，这种“基于CPU负荷重新分配负载”的行为，虽然实现起来并不难，却没有多少实用价值。理论分析，模拟数据

和生产实践都表明，ROUND ROBIN，RANDOM, 和根据负荷的“自适应反馈算法”，在性能方面没有很大区别。这是 相关数据在多数操作系统或

者计算机网络教科书里都有描述。这听起来似乎有些奇怪，但不过是“大数定理”的必然结果。

4。从现实商业服务器支持角度看：BANQ描述的“根据CPU重新分配负荷”的行为，至少在WEBLOGIC, WEBSPHERE两者都不支持。Weblogic和

WebSphere只支持 Round Robin, 加权 Round Robin和随机 这三种算法（Web集群和EJB集群都一样！）。 JBoss支持一种“First Available”

的算法，但实质上是随机算法。
当然，WebLogic允许用户自己开发和定制负载分配算法，但是未见有记录表明用户通过自定义负载分配算法提高了性能的。否则，IBM，BEA，

JBOSS会只支持这三种算法么？
并且，对于 WEBLOGIC 和 WEBSPHERE, 缺省状况下即使是 REMOTE EJB ， 在JNDI解析时也会被“本地优先”，根本不会做负载平衡。
再者，一旦会话建立，后续请求会由于“Session Affinity”优化而绑定在同一节点，也不会做负载平衡。