上一篇：项目推出：针对WLS 7和8.1的COMMONJ WORK MANAGER >>

JMS集群第1部分

　本文是关于JMS集群的由两部分组成的系列文章中的第1部分。在这一部分中，将讨论对诸如队列、主题和连接工厂之类的JMS资源实现集群的一些基础方面，并举例说明在WebLogic集群中配置集群目的地的具体步骤。第2部分将在几个设计和配置策略的上下文中讨论JMS集群，这些策略演示了如何创建有效的和最好的JMS架构。

　　WebLogicv7.0中引入了JMS集群。本文将讨论WebLogic 8.1（SP3）中的JMS集群的一些基础方面。

集群JMS资源

　　任务关键型系统需要具备可伸缩性、高可用性和容错性。在J2EE中提交的标准提供了构建满足这些要求的健壮架构所需的框架。JMS为企业系统提供了消息传递的基础。要求零停机时间的JMS系统，比如金融企业中的那些系统，必须提供高可用性以及JMS资源的故障转移，以满足严格的服务水平协议。因此，采用JMS实现很关键，它能够在分布式JMS目的地中对消息流量进行负载平衡的同时集群JMS资源，如队列、主题和连接工厂，并且具有高可用性。

　　WebLogic的JMS 是一个支持JMS标准的完整消息传递实现。它还提供服务，因此，集群的JMS配置可以负载平衡消息，并为所有类型的JMS资源提供高可用性。在WebLogic集群中，可以将普通队列和主题配置成由许多分散在物理机器中的物理目的地组成的分布目的地，从而创建一个高可用性的消息层。连接工厂也可是分布式的。它让WebLogic负载平衡来自JMS客户的连接请求，并透明地将消息流量指向预期的目的地，或是在目的地失效事件中重定向消息。

分布式目的地

　　分布式目的地代表一组物理队列或主题，它们的成员驻留在WebLogic集群中的一台JMS服务器上。分布式目的地被绑定到集群范围内的JNDI树中的一个逻辑JNDI名。WebLogic将在分布式目的地成员之间负载平衡消息，如果目的地成员失效，那么消息将被透明地重定向到分布式目的地内的另一个成员。从JMS客户的角度来看，分布式目的地看起来像是一个普通目的地，这意味着用普通目的地配置的现有JMS应用程序能够改变其配置，定向到分布式目的地，而不会影响JMS客户或应用程序代码。

分布式队列

　　分布式队列代表一组物理队列。如果QueueSender是利用分布式队列的JNDI名创建的，那么从QueueSender发送的任何消息都只分发给一个物理队列目的地。每次发送一条消息，通知哪个成员将得到该消息的时候，才进行决策。该决策基于由WebLogic提供的负载平衡算法。默认负载平衡方案是轮询，但是也可以使用随机负载平衡方案来随机将消息分发给目的地成员。

　　当使用分布式队列名创建QueueReceiver时，它会连接到物理队列成员，而且与QueueSender不同，它会保留到该目的地的连接，直到QueueReceiver失去连接为止。

　　图1描述了JMS如何在WebLogic集群内与分布式队列交互。在图中，分布式队列（DQ，Distributed Queue）有两个物理队列成员：MQ1和MQ2，它们分别驻留在服务器实例1和实例2上。队列接收者（QR，Queue Receiver）从MQ1得到消息，并在该连接关闭之前一直保留到MQ1的连接。队列发送者（QS，Queue Sender）向分布式队列DQ发送消息。只有一个物理队列成员得到发送给分布式队列的消息，而且如图所示，QS发送的第一条消息，即Message 1，是经过负载平衡的，并被发送给MQ1。下一条消息，即Message 2也经过负载平衡，并被发送给序列中的下一个队列成员MQ2。图示使用了轮询负载平衡策略，该策略按照顺序选取服务器实例。

　　当消息发送到没有消费者的分布式队列成员时，在消费者可用之前，该消息将一直保留在队列中。而且，如果该队列成员失效，那么该队列中挂起的所有消息在队列成员重新可用之前均不可用。在分布式队列的每个成员上配置转发延迟（Forward Delay）可防止这种情况发生。该选项自动将来自无活跃消费者队列成员的消息转发给有活跃消费者的队列成员。默认情况下，转发延迟是禁止的。我们将在下面讨论如何配置这个目的地参数。

　　如果某个物理队列成员失效，那么JMSException将通知连接它的所有消费者，这些消费者实际上将失去它们与队列的连接。对于同步消费者，直接将异常返回给客户。对于异步消费者，其队列会话是使用ExceptionListener配置的，所以它将发送一个ConsumerClosedException。在任何一种情况下，假定失效只限于该物理队列成员，那么JMS连接和会话仍然有效。客户应用程序仅关闭队列接收者，并用同一JMS会话再创建它。

分布式主题

　　分布式主题代表一组物理主题。JMS客户应用程序可使用分布式主题名创建主题消息生产者和消费者。应用程序不知道分布式主题中有多少个物理目的地成员，所以，在使用这类集群JMS资源时，这消除了任何特定编程考虑。

　　当以分布式主题名创建的TopicPublisher发布消息时，该消息被自动发送给分布式主题的所有成员，因此所有订户都将收到该消息。即使使用物理主题目的地的JNDI名，而不是使用分布式主题的JNDI名来创建TopicPublisher，也会将消息转发给所有主题成员目的地。

　　发布到分布式主题的非持久性消息只发送给可用的主题目的地。如果应用程序使用持久性消息，那么使用一个持久存储器来配置每个主题成员目的地是一个不错的主意。当发布一条关于分布式主题的持久性消息来避免丢失消息时，WebLogic偏爱使用持久存储器配置的主题目的地。如果发布持久性消息时有任何主题成员不可用，那么消息将会保存在有持久存储器的主题成员上，并在其余主题成员可用时再转发给它们。

　　用分布式主题名创建的TopicSubscriber与分布式主题的一个物理主题成员连接。在目的主题成员失效之前，连接一直有效。如果在这种情况发生时，会向主题订户发送一个JMSException，该异常与目的地队列成员失效时发送的异常一样。如果有活跃订户的主题目的地成员失效，那么在该主题目的地成员可再次获得消息之前，失效之后发送给该分布式主题的任何持久消息都不会分发给断开连接的订户。相反，失去与分布式主题成员连接的订户永远不会获得非持久消息。

　　图2举例说明了在WebLogic集群中JMS客户如何与分布式主题交互。图中分布式主题（DT，Distributed Topic）由两个物理主题成员T1和T2组成，它们分别驻留在服务器实例1和实例2上。主题订户（TS，Topic Subscriber）从T1获得消息，并且在该连接关闭或丢失之前保持与该主题成员的连接。主题发布者（TP，Topic Publisher）将消息发送给分布式主题（DT，Distributed Topic）。所有物理主题成员都获得发送给该分布式主题的消息。如图所示，TP将消息1发布给分布式主题DT，而DT又将它发送给主题成员T1和T2。下一条消息Message 2也都发送给两个主题成员。

集群连接工厂

　　连接工厂也可利用JMS集群的能力来提供负载平衡、高可用性和对JMS客户的故障转移。

　　连接工厂可以以集群为目标，或是以集群中的单个WebLogic实例为目标，而不管那些WebLogic实例是否驻留在一台JMS服务器上。从架构师的角度来看，在决定连接工厂以什么为目标之前，需要考虑应用程序中JMS客户机的物理位置以及它们要访问的目的地。比如，如果外部客户机使用以集群中多个WebLogic实例为目标的连接工厂，那么关于使用哪个连接工厂以及JMS连接驻留在哪一台JMS服务器的决定是负载平衡的。

　　如果新的JMS连接以及本地JMS服务器在同一物理机器上，那么连接路由的效率可能会很低。为了避免不必要的连接路由，要确保JMS应用程序中每个连接工厂的Server Affinity参数都被启用。可以通过导航到“Services/JMS/Connection Factories”节点，从WebLogic管理控制台修改该设置。然后从列表中选择连接工厂，滚动到“General”选项卡的底部就可找到“Server Affinity”参数。

　　相反，如果连接工厂在物理上处于和所期望的目的地驻留的JMS服务器相同的WebLogic实例上，那么试图定位连接工厂并创建JMS连接的内部JMS客户机就不会招致浪费的远程连接。连接工厂对内部JMS客户机使用的默认负载平衡策略是预防性的，因为WebLogic优先选择配置的连接工厂和JMS服务器，以避免创建远程连接。

　　在不同的JMS应用程序场景上下文中配置和建立连接工厂目标的细节将在本文的第二部分中讨论。

配置分布式目的地

　　要配置分布式队列或主题，可以打开WebLogic管理控制台并导航到“Services/JMS/Distributed Destinations”节点（图3）。

　　现在可以创建分布式主题或分布式队列了。在本例中，我们将创建一个分布式队列。单击“Configure a new Distributed Queue”以继续。图4显示了创建分布式队列的配置参数。

　　名称：分布式队列目的地的惟一逻辑标识符。
　　JNDI名：集群范围内的JNDI的查找别名。
　　负载平衡策略：用于确定分布式目的地成员间的消息分布的算法。
　　转发延迟：只用于分布式队列。它定义了在将其挂起消息转发给其他有活跃消费者的队列成员之前，没有消费者的分布式队列成员等待的时间。

　　一旦创建了分布式队列，请单击“Thresholds and Quotas”选项卡。该屏幕上的参数都有很好的文档描述，因此我们将略过每个设置的要点，但还是要大致介绍一些参数，这些参数可配置最大消息配额、消息阈值、最大消息大小和消息分页的字节数。这些设置全局应用于所有属于该分布式目的地的物理成员。

　　现在，我们已经为向分布式队列添加物理队列成员做好了准备。如果WebLogic域中有您打算指定为新创建的分布式队列成员的队列目的地，那么，请单击“Members”选项卡（图5），然后单击“Configure a new Distributed Queue Member”。

　　在下一屏中，输入物理队列成员的配置参数（图6）。

　　名称：成员目的地的惟一逻辑标识符。
　　JMS队列/主题：可用队列的清单，从中可以选择新分布式队列成员的物理目的地。
　　权重：控制轮询算法的消息负载平衡的整数。权重与同一分布式队列中的其他队列成员目的地有关；较高的值指出该成员获得的消息要多于那些设置了较低值的成员获得的消息。

　　单击“Create”按钮以创建新的分布式队列成员。可用重复该步骤将其他成员添加到分布式队列中。

　　WebLogic提供自动创建物理队列或主题，并将它们分配给分布式目的地的简便功能。

　　要使用该功能，请单击“Auto Deploy”选项卡（图7），然后单击“Create members on the selected Servers (and JMS Servers)”。

　　在下一屏中，有直接选择作为分布式目的地目标的WebLogic实例或WebLogic集群的选项。

　　如果希望直接指定WebLogic实例为目标，那么请执行以下操作：
　　选择（none），然后单击“Next”（图8）
　　选择要在其上创建目的地成员的WebLogic实例，然后单击“Next”（图9）
　　选择要在其上部署目的地成员的JMS服务器。然后单击“Next”（图10）
　　如果希望以WebLogic集群为目标，请执行以下操作:
　　选择集群名，然后单击“Next”（图8）
　　选择要在其上创建目的地成员的WebLogic实例，然后单击“Next”（图11）
　　选择要在其上部署目的地成员的JMS服务器。然后单击“Next”（图12）

　　在应用了一些配置更改之后，WebLogic自动在选定的JMS服务器上创建成员目的地。单击“Members”选项卡就可以看到新产生的成员目的地列表（图13）。

结束语

　　至此，您应该理解了JMS集群的基本特性，以及它所提供的分布式资源的类型。下一篇文章将讨论针对内部生产者/消费者和外部生产者的JMS应用程序设计策略、高度分布式和负载平衡的JMS应用程序，以及使用JMS集群时要遵循的最佳实践和规则。

返回顶部

下一篇：WebLogic平台的Web SSO（SAML）解决方案 >>