[转帖]weblogic群集
weblogic从5.1的版本起就支持集群技术.从网上down的版本是没有集群支持的。license key中有控制。 [@more@]
weblogic从5.1的版本起就支持集群技术.从网上down的版本是没有集群支持的。license key中有控制。
关于wls 的集群原理，附上一个哥们写的东西，供大家参考。
(是写在wls5.1应用的时候，2000年，不过原理是一样的。)
CLUSTER概要
一、 Cluster的概念及优势
Weblogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可****的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个。集群技术有两个最明显的特色：
(1)可伸缩性：Cluster对加入其中的Server在性能上没有限制，为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。
(2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。
二、Cluster的工作机制
每一个Clustered service,在每一个server上都会有一个instance，即一个replica，这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信，当客户端请求该service时，实际上是向stub发出请求，stub根据不同的算法调用集合中某一replica，如果调用失败，stub会检测到错误并重新调用其它的replica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。
Weblogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。
为了提高Cluster的可伸缩性，必须保证充分利用每一个Server。Weblogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡，从而使每一个Server都得到充分的利用。
为了使Cluster具有高可用性，必须具备故障恢复的能力，这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)，容错功能自动实现。而有些情况下，重新调用可能会导致某一service被请求了多次的错误结果。例如：客户端C请求Clustered购物车服务中的additem()方法，replica-aware stub接收到请求，根据算法调用Server1上的service,Server1响应请求并返回结果，但在结果成功到达客户端之前，Server1出现错误。此时stub接收到错误信息，因此重新调用Server2上的这一方法，但实际上Server1已经将item加入购物车，这样就造成重复。为了解决这种问题，可以为服务添加一个唯一标识，如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。
三、 Cluster的命名服务
在Weblogic Server中使用命名服务时，客户端通过JNDI存取service，JNDI tree上绑定了Server提供的所有的公共服务。Server提供一个新的service时，是将service以某一名称绑定到JNDI tree上，客户端和Server建立连接并按照名称获取相应的stub。
Custer扩展了Server的这种命名服务机制，它不仅包含了每一个Server上的非Clustered的stub,而且包含了多个Server间的Clustered 的replica-aware stub。
四、 Cluster的服务类型
在Weblogic中，有多种服务可以进行cluster，如：RMI对象、EJB、Servlets、Jsp、Web Application。
（1）RMI和EJB Clustering
RMI和EJB对象在Cluster过程中使用JNDI命名服务机制。RMI和EJB对象发送remote stubs到客户端，客户端获取的这些stubs可以是已经clustered的，也可以是没有clustered的。对于Clustered的服务，Stubs根据负载均衡和容错的不同需求调用Cluster中合适的Server；而对没有Clustered的服务，所有对此stub的调用只能由提供此服务的Server来处理。
有些有状态的RMI和EJB对象是不可以进行clustered的，因为客户端必须总是和同一个Server上的对象实例相联系。所有的EJB都是clusterable，虽然EJB也有有状态的，但是EJB home interface 都是无状态的，可以进行clustered，这样就可以从JNDI tree上获取 Clusterable EJB 的home stub 对象。然后通过home stub的方法创建或检索相应的EJB bean,若为stateful session bean 或entity bean，那么此时得到的stub就是不可clusterable。为了使有状态的对象可以更好的cluster，可以将一些操作作为一个事务来执行，如果工作中的Server出现意外，可以重新获取此对象并进行事务操作。
RMI和EJB不同，RMI没有定义有状态和无状态分类，因此必须特意绑定一个有状态的RMI对象到Server上。可以仿效EJB home interface的方式即客户端从JNDI tree上获取一个clusterable factory method,然后factory method 可以调用集群中的任意一台Server,但是被调用的Server上必须有由此factory调用的对象。
（2）Clustered Servlets
Servlets也是可以进行Cluster的。对于Servlets，它用replica-aware proxy替代了replica-aware。这个proxy接受web server上所有请求，并转给集群中的某一Server。Proxy对cluster的所有请求进行负载均衡，并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时，proxy按照负载均衡算法选择一台Server保存session，此后，所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时，无法保存客户端状态信息，所以session会被复制下来，并且session的所有变化都会在备份中进行及时更新，这样，当原有Server在响应请求过程中失败时，proxy会立即获取session的备份，并由此继续响应客户端请求，同时做新的复制。
(3)JDBC clustering
为了利用Weblogic Server cluster的负载均衡和容错的性能，Weblogic JDBC连接池也可以在replicated naming tree上注册。通常情况下，cluster中的每一个Server都进行连接池属性配置来访问同一个后端的DBMS实例，即对相同数据库的访问，每一个Server都有一个连接池。然后通过在配置文件中定义一个DataSource属性来在naming tree 上注册连接池。客户端使用Weblogic JDBC/RMI JDBC 驱动程序从cluster中获取数据库连接，即客户端按照DataSource name获取连接池，然后按照负载均衡的算法选择相应的Weblogic Server来响应请求。
http://chinaunix.net/jh/28/125193.html
关于wls 的集群原理，附上一个哥们写的东西，供大家参考。
(是写在wls5.1应用的时候，2000年，不过原理是一样的。)
CLUSTER概要
一、 Cluster的概念及优势
Weblogic支持集群技术，即让一组Server指向同一域名一起工作从而提供一个更强大、更可****的应用平台。对于客户端而言，无论Cluster中有几个Server在工作，看上去都是一个。集群技术有两个最明显的特色：
(1)可伸缩性：Cluster对加入其中的Server在性能上没有限制，为了提高性能，当客户端的请求大幅增加时，可以动态地向Cluster中添加Server。并且，配置Cluster当一台机器的资源没有被完全利用时，可以在同一机器上启动多个Server，但要求每一个Server使用不同的IP，而不能用同一IP的不同端口。
(2)高可用性：由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中，因此相同的请求可以有多个Server提供，并且Server间还可以复制状态信息。这样，当其中某一Server宕机或无法响应请求时，其它的Server会立即接管它的任务，从而把应用和客户端完全隔离开来。
二、Cluster的工作机制
每一个Clustered service,在每一个server上都会有一个instance，即一个replica，这些replicas集合在一起形成一个replica-aware stub。这些stubs负责客户端与相关的服务器段对象的通信，当客户端请求该service时，实际上是向stub发出请求，stub根据不同的算法调用集合中某一replica，如果调用失败，stub会检测到错误并重新调用其它的replica。Cluster支持多种算法：随机、轮循、基于性能的负载均衡的轮循(Weight-based round-robin)、根据参数值调用(Parameter-based routing)。
Weblogic Cluster通过负载均衡和容错最大程度的实现了它的可伸缩性和可用性。
为了提高Cluster的可伸缩性，必须保证充分利用每一个Server。Weblogic可以在不同平台、不同性能的机器上安装Server并进行Cluster,然后采用Weight-based round-robin算法达到负载均衡，从而使每一个Server都得到充分的利用。
为了使Cluster具有高可用性，必须具备故障恢复的能力，这一点可以通过replica-aware stub的容错功能来实现。Stub 主要是通过在检测到错误信息时重新进行调用的方式实现容错。当重新调用不会导致错误的结果时(如stub确认failed server不能接收到请求)，容错功能自动实现。而有些情况下，重新调用可能会导致某一service被请求了多次的错误结果。例如：客户端C请求Clustered购物车服务中的additem()方法，replica-aware stub接收到请求，根据算法调用Server1上的service,Server1响应请求并返回结果，但在结果成功到达客户端之前，Server1出现错误。此时stub接收到错误信息，因此重新调用Server2上的这一方法，但实际上Server1已经将item加入购物车，这样就造成重复。为了解决这种问题，可以为服务添加一个唯一标识，如上述的additem()方法中可添加一个参数——序列号。每一个item有一个唯一的sequence,相同sequence的item不能被重复添加。
三、 Cluster的命名服务
在Weblogic Server中使用命名服务时，客户端通过JNDI存取service，JNDI tree上绑定了Server提供的所有的公共服务。Server提供一个新的service时，是将service以某一名称绑定到JNDI tree上，客户端和Server建立连接并按照名称获取相应的stub。
Custer扩展了Server的这种命名服务机制，它不仅包含了每一个Server上的非Clustered的stub,而且包含了多个Server间的Clustered 的replica-aware stub。
四、 Cluster的服务类型
在Weblogic中，有多种服务可以进行cluster，如：RMI对象、EJB、Servlets、Jsp、Web Application。
（1）RMI和EJB Clustering
RMI和EJB对象在Cluster过程中使用JNDI命名服务机制。RMI和EJB对象发送remote stubs到客户端，客户端获取的这些stubs可以是已经clustered的，也可以是没有clustered的。对于Clustered的服务，Stubs根据负载均衡和容错的不同需求调用Cluster中合适的Server；而对没有Clustered的服务，所有对此stub的调用只能由提供此服务的Server来处理。
有些有状态的RMI和EJB对象是不可以进行clustered的，因为客户端必须总是和同一个Server上的对象实例相联系。所有的EJB都是clusterable，虽然EJB也有有状态的，但是EJB home interface 都是无状态的，可以进行clustered，这样就可以从JNDI tree上获取 Clusterable EJB 的home stub 对象。然后通过home stub的方法创建或检索相应的EJB bean,若为stateful session bean 或entity bean，那么此时得到的stub就是不可clusterable。为了使有状态的对象可以更好的cluster，可以将一些操作作为一个事务来执行，如果工作中的Server出现意外，可以重新获取此对象并进行事务操作。
RMI和EJB不同，RMI没有定义有状态和无状态分类，因此必须特意绑定一个有状态的RMI对象到Server上。可以仿效EJB home interface的方式即客户端从JNDI tree上获取一个clusterable factory method,然后factory method 可以调用集群中的任意一台Server,但是被调用的Server上必须有由此factory调用的对象。
（2）Clustered Servlets
Servlets也是可以进行Cluster的。对于Servlets，它用replica-aware proxy替代了replica-aware。这个proxy接受web server上所有请求，并转给集群中的某一Server。Proxy对cluster的所有请求进行负载均衡，并且当请求失败时会进行恢复处理。Proxy还可以在cluster中特别是Server没有正常完成请求响应时保持session状态。当session初始化时，proxy按照负载均衡算法选择一台Server保存session，此后，所有与此session相关的请求都由这同一台Server处理。为了避免当此Server出错时，无法保存客户端状态信息，所以session会被复制下来，并且session的所有变化都会在备份中进行及时更新，这样，当原有Server在响应请求过程中失败时，proxy会立即获取session的备份，并由此继续响应客户端请求，同时做新的复制。
(3)JDBC clustering
为了利用Weblogic Server cluster的负载均衡和容错的性能，Weblogic JDBC连接池也可以在replicated naming tree上注册。通常情况下，cluster中的每一个Server都进行连接池属性配置来访问同一个后端的DBMS实例，即对相同数据库的访问，每一个Server都有一个连接池。然后通过在配置文件中定义一个DataSource属性来在naming tree 上注册连接池。客户端使用Weblogic JDBC/RMI JDBC 驱动程序从cluster中获取数据库连接，即客户端按照DataSource name获取连接池，然后按照负载均衡的算法选择相应的Weblogic Server来响应请求。
http://chinaunix.net/jh/28/125193.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/509190/viewspace-819125/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/509190/viewspace-819125/