yuxie
2005-10-25 11:31
呵呵,事情可能不是这个样子的……
如果有一台机器坏了,或者网络有问题,分发器还是继续将request发往那台坏的服务器,那么我们也就不需要session复制了,因为那将是毫无意义的。
别的app server怎么实现的我不知道,只能说一下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.

如果要在扯上多次请求之间涉及的长事务……还没研究,不过和用不用ejb无关,因为web都死掉了

yuxie
2005-10-25 11:36
至于判断哪个server占的内存比较高(cpu可能比较难,不过thread\队列请求数等是可以判断的),这个也可以通过自己编程jmx等来实现,甚至可以加数据挖掘来动态判断发送到哪个server,最近研究了一下f-p growth :)

当然,麻烦多多~
我不知道ejb容器实现这个是否轻而易举,不多作评论~

banq
2005-10-25 15:55
yuxie说话很有趣,"不过和用不用ejb无关,因为web都死掉了 "
其实集群中尽量降低Web端负担,比如HttpSession不要放太多东西,这样Web服务器之间复制工作负担就小了,Web服务器只管作为客户端和EJB传输,有EJB的服务器叫应用服务器,应用服务器管理集群复杂计算。

Web只是EJb的一种客户端,RMI/XML-RPC/Web Service/Corba都是EJB企业应用服务器的客户端。

Web只是一个简单的客户端,不是核心,这和一般人以Web为核心思维正好相反。

Kyle_Yin
2005-10-26 04:41
yuxie那句话其实说得很到位:EJB的客户端,也就是WEB,都死了,EJB的集群不集群当然已经毫无意义。 集群的“FAILOVER”,指的是服务端死掉的情况下,如何把请求导向备份服务。
事实上,所有支持EJB集群的应用服务器,在WEB,EJB“共同部署”的情况下(现实EJB生产环境至少占90%以上),EJB的集群是被缺省关闭的。

另外,“分布事务”和集群的两特性-“load balance, fail-over”是互为正交的概念。其实,“分布事务”和集群本身也互为正交,甚至和你的环境有多少机器也没有直接关系。

要理解集群,比纸上谈兵更好的方法是写个HELLO程序试验一下。

回到楼主的问题,Wang Yu的那篇文章总结了几个不错的建议,比如要SERIALIZABLE,SESSION ATTRIBUTE之间不要互相形成“引用依赖”。但是这些都是死的理论知识,最有效的办法,就是写个小程序测试一下FAIL-OVER情况下的行为。另外,在考虑“集群”概念的时候,很重要的是要弄清楚谁是客户端,谁是服务端,所谓“FAIL-OVER”是谁FAIL了之后,保证对谁的请求继续服务。

vcshcn
2005-10-26 12:21
web层为什么不能负载平横还不太明白。我在琢磨琢磨

vcshcn
2005-10-26 12:22
sorry,说错了。
如果连failover都不能,那这个东西也没什么用啊

Kyle_Yin
2005-10-27 07:13
web集群当然可以FAIL-OVER,之所以有SESSION REPLICATION,原因就是需要实现FAIL-OVER.
如果只是需要实现负载平衡,只需要两个互相独立的服务器和一个负载平衡器就可以。FAIL-OVER从这个意义上,可以说是集群功能的基本标志。

banq
2005-10-27 12:21
>之所以有SESSION REPLICATION,原因就是需要实现FAIL-OVER.
Session复制不是容错Failover吧?

failover是在机器当机的情况下,整个系统能够保证平稳运行,用户没有任何察觉。

Session复制只是为了负载平衡服务的,一个用户请求第一次可能被分发到A服务器,这是一个登陆请求,这样Session中保存其登陆信息,但是第二次请求可能被分发到B服务器,如果没有Session复制,B服务器的Session中没有其登陆信息,所以可能要求其重新登陆;当然如果该系统激活Cookie登陆,就无法Session复制了。

TSS网站就采取第二种方案,杜绝Session,使用客户端cookie,这样做的好处降低Web服务器的负载,因为Web服务器主要功能是维持客户端的TCP连接,如果它被分散去做持续纵向Session复制的话,实际利用效率会打折。

以上观点欢迎讨论。

yuxie
2005-10-27 13:25
“failover是在机器当机的情况下,整个系统能够保证平稳运行,用户没有任何察觉。”
wap集群可以做到。

“Session复制只是为了负载平衡服务的,一个用户请求第一次可能被分发到A服务器,这是一个登陆请求,这样Session中保存其登陆信息,但是第二次请求可能被分发到B服务器,如果没有Session复制,B服务器的Session中没有其登陆信息,所以可能要求其重新登陆;当然如果该系统激活Cookie登陆,就无法Session复制了。”
上边这句话错误。应用中分发器不会那么愚蠢。具体的实现请参看相应的文档。

搞了半天banq仅仅是因为分发器的原因鄙视web集群?那么当您认识到自己的错误之后,会不会收回以前的观点呢?


另外,程序中能杜绝session确实很让人羡慕,但是实际应用中,如果碰到需要身份认证的,却很难做到比session更好的实现,感觉不如尽量减少session里边的数据来的现实。

banq
2005-10-27 15:56
我的意思是:Session复制是可有可无,如果没有Session复制就更好,因为这会降低Web服务器接收客户端的处理能力。

failover主要是指状态的恢复,别因为一台服务器当机,把保存在内存中的状态丢失了,Session Failover只能解决保存在Session的状态的failover。

而我们有提倡尽量少用Session,所以一般不用Session来保存状态,在这个思路下,Session Failover等于一个空概念,个人认为没有实用价值。

Cache等failover概念比较重要。
另外负载平衡还有一个动态概念,EJB提供远程方法调用,所以每时每刻运行时,都有可能保持各个服务器之间负载相当,这种能力我个人认为很难靠外部技术实现的。

可以用一个比喻来解释:你作为一个外部东东,要了解我内部的运行,你肯定要派个东东深入我内部监视,但是你的东东又不要影响我运行,不成为我的负担,很难啊。单纯靠外部技术的网络信号是很难的。

所以集群在Web实现很简陋,不能实现大幅度拓展服务器能力。

Kyle_Yin
2005-10-28 01:56
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状态,采用数据库状态会带来频繁的数据库操作,而客户端状态首先未必能够容纳那么多数据,即使能够容纳,每次请求都要附带大量状态数据,会对网络传输造成压力。

> REPLICATION,原因就是需要实现FAIL-OVER.
> Session复制不是容错Failover吧?
>
> failover是在机器当机的情况下,整个系统能够保证平稳运行
> 没挥腥魏尾炀酢?
>
> Session复制只是为了负载平衡服务的,一个用户请求第一次?
> 能被分发到A服务器,这是一个登陆请求,这样Session中保存
> 涞锹叫畔堑诙吻肭罂赡鼙环址⒌B服务器,如果没有
> ession复制,B服务器的Session中没有其登陆信息,所以可能
> 笃渲匦碌锹剑坏比蝗绻孟低臣せCookie登陆,就无法Ses
> ion复制了。
>
> TSS网站就采取第二种方案,杜绝Session,使用客户端cookie
> 庋龅暮么档Web服务器的负载,因为Web服务器主要功?
> 是维持客户端的TCP连接,如果它被分散去做持续纵向Session
> 粗频幕埃导世眯驶岽蛘邸?
>
> 以上观点欢迎讨论。
>

Kyle_Yin
2005-10-28 02:22
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的。

不明白BANQ为什么对EJB集群情有独衷。更不动所谓WEB集群“简陋”是什么意思。二者的实现,在代码层面都是用同样的代码,何来一者简陋另一者高级?

> 我的意思是:Session复制是可有可无,如果没有Session复制
> 透茫蛭饣峤档Web服务器接收客户端的处理能力。
>
> failover主要是指状态的恢复,别因为一台服务器当机,把保
> 嬖谀诖嬷械淖刺Я耍Session
> Failover只能解决保存在Session的状态的failover。
>
> 而我们有提倡尽量少用Session,所以一般不用Session来保存
> 刺谡飧鏊悸废拢Session
> Failover等于一个空概念,个人认为没有实用价值。
>
> Cache等failover概念比较重要。
> 另外负载平衡还有一个动态概念,EJB提供远程方法调用,所?
> 每时每刻运行时,都有可能保持各个服务器之间负载相当,这
> 帜芰ξ腋鋈巳衔苣芽客獠考际跏迪值摹?
>
> 可以用一个比喻来解释:你作为一个外部东东,要了解我内部
> 脑诵校憧隙ㄒ筛龆钊胛夷诓考嗍樱悄愕亩植
> 要影响我运行,不成为我的负担,很难啊。单纯靠外部技术的
> 缧藕攀呛苣训摹?
>
> 所以集群在Web实现很简陋,不能实现大幅度拓展服务器能力?

banq
2005-10-28 09:58
很多人还是不理解EJB动态负载平衡的优势,前面我已经举例了,Web负载平衡是对请求信号分发,但是每次请求对CPU的负载肯定是不一样的,主要取决于这个请求调用的那个组件方法(EJB方法)的运行量,根据业务逻辑不同,不同EJB方法运行占据CPU就不一样。

所以,”Web负载平衡是对请求信号分发“方式很难将每个服务器负载都平衡成50%,因为EJB方法运行量不一样,有的服务器对一个请求可能处理耗费80%CPU,但是运气不好的话,下一个需要大负载的请求又可能发给它处理,累死它。

而EJB的远程方法和JNDI则可以平衡这种处理,当这台服务器负载已经达到80%,又有请求发给它,它会通过JNDI和远程调用,将这个请求调用的EJB方法转发调用其他负载较低的服务器上的EJB。

我想我说的够明白了。这就是EJB集群的智能,这也是EJB诞生的首要原因,因分布式计算而生。

banq
2005-10-28 10:31
接着谈failover,上述服务器转发调用其他服务器时,就需要通过JNDI查询了(因为这是EJB调用的首要步骤),这时failover就会被激活,因为总不能找一个当机的服务器给它用吧.

负载平衡以及失效转发行激活有三种方式:





另外负载平衡以及失效转发行激活是时刻都可能发生,但是因为这样耗费性能,所以,你可以事先设定不要让其频繁发生。

banq
2005-10-28 10:34
EJB的集群如此复杂,因此EJB在当初设计时,很难在性能和OO设计之间取得一个平衡,所以EJB2.1之前都是倾向性能,忽视OO设计,而后者成为Spring等开源软件的攻击目标,当然EJB3又一次取得了平衡。

如果Web集群和EJB集群差不多,何必走这么多弯路,何必发明EJB呢,这个基本常识我想初学者也会明白的。

猜你喜欢