关于在集群中编程的问题

发布于:2021-10-16 20:39:18

注意以下几点:(目前只想到这些)
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 绝对不是为负*胶庥玫摹>蠖嗍榭鱿拢涸*胶馄鞫加幸桓龌咎匦越凶觥癝ession Affinity”。也就是说,同


一个SESSION,即使在负*胶獾那榭鱿拢彩怯赏桓鼋诘憷刺峁┓竦摹U馐切阅苡呕谋厝灰蟆
这首先要从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实现的方式,取决于不同的应用服务器是不同的。软件负*胶馄饕话闶怯τ梅衿鞯囊桓鯳EB SERVER插件。这个插件里就


内建了SESSION AFFINITY逻辑。硬件负*胶馄饕仓С諷ESSION AFFINITY,当然这需要一些配置。详见(http://e-


docs.bea.com/wls/docs81/cluster/load_balancing.html#1044135)
------------------------
综上,负*胶庠诰蠖嗍榭鱿拢环⑸诮ESSION之前。一旦SESSION建立,那么SESSION AFFINITY会保障同一SESSION绑定在一个节点


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


要对每次请求都做负*胶猓辛街盅≡瘢1。你完全不*闲阅埽ü渲帽Vっ扛銮肭蠖甲鲎刺粗啤U獠皇敲靠钣τ梅衿鞫贾С值摹U


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


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


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


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


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


2。EJB的负*胶猓膊皇撬健笆笔笨炭潭荚诜⑸薄JB的负*胶猓小癝ESSION AFFINITY”的优化,当然这是针对于SFSB。对于


SLSB而言,既然没有状态,和WEB负*胶饩筒痪弑缚杀刃浴
EJB的负*胶猓坏诟拍钌希踔猎谒惴ㄉ希迪稚希己蚖EB集群完全一致。


并且,EJB的负*胶夂 WEB负*胶庀啾龋饔靡〉枚唷U庋档脑颍


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


*胶饴呒墙ㄈ朐赟TUB里的。既然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。从负*胶獾氖迪只*嵌冉玻挥腥怂礧EB负*胶馑惴ㄖ挥蠷OUND ROBIN一种。基于CPU负载的*衡算法,也就是BANQ称作“EJB集群的智


能”,同样也适用于WEB负*胶狻U庖坏闵螮JB集群和WEB集群毫无区别。
BANQ所谓“EJB集群的智能”,有两个要求:CPU负荷检测,和请求重定向。这两个要求,WEB容器都可以轻松实现。有什么理由认为EJB容器可


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


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


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


难道EJB的CPU负荷模式莫名其妙地会比WEB请求更均匀?另外,这种情况,是计算机科学中负*胶夥矫娴木洳±砬榭觯卸嘀址椒ń饩觥W


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


负*胶獠皇鞘裁碋JB独有的特殊算法。EJB负*胶馑惴ɑ旧隙际羌扑慊蒲Ю锎蠹叶炷芟甑亩鳌JB和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。从负*胶獾氖迪只*嵌冉玻挥腥怂礧EB负*胶馑惴ㄖ挥蠷OUND ROBIN一种。基于CPU负载的*衡算法,也就是BANQ称作“EJB集群的智


能”,同样也适用于WEB负*胶狻U庖坏闵螮JB集群和WEB集群毫无区别。
BANQ所谓“EJB集群的智能”,有两个要求:CPU负荷检测,和请求重定向。这两个要求,WEB容器都可以轻松实现。有什么理由认为EJB容器可


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


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


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


难道EJB的CPU负荷模式莫名其妙地会比WEB请求更均匀?另外,这种情况,是计算机科学中负*胶夥矫娴木洳±砬榭觯卸嘀址椒ń饩觥W


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


负*胶獠皇鞘裁碋JB独有的特殊算法。EJB负*胶馑惴ɑ旧隙际羌扑慊蒲Ю锎蠹叶炷芟甑亩鳌JB和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”优化而绑定在同一节点,也不会做负*胶狻



--------------------------------------------------------------------------------------
http://www.jdon.com/jive/thread.jsp?forum=46&thread=23302&start=0&msRange=15
致谢: Kyle Yin ;彭晨阳(网名: 板桥里人)
????? http://www.jdon.com/
注:以上文章观点,搜集而成,仅代表个人理解,欢迎讨论学*!

相关推荐

最新更新

猜你喜欢