Sun Java System Message Queue 3.7 UR1 技术概述

第 4 章代理群集

Message Queue 支持使用代理群集：代理群集是一组协同工作为客户端提供消息传送服务的代理。使用群集，管理员可以将客户端连接分布在多个代理中，从而使用消息流量来扩展消息传送操作。

本章讨论此类代理群集的体系结构和内部功能，其中包括下列主题：

请注意，代理群集提供服务可用性，但不提供数据可用性。如果某个群集内的一个代理发生故障，则连接到该代理的客户端能够重新连接到该群集内的另一个代理，但是在这些客户端重新连接到备用代理时可能会丢失一些数据。

群集体系结构

图 4–1 显示 Message Queue 代理群集的体系结构。群集内的每个代理直接与其他所有代理相连。每个客户端（消息生成方或使用方）都有一个本机代理，借助它，该客户端可直接进行通信以收发消息，就好像该代理是群集内的唯一代理。实际上，本机代理与其他代理协同工作，为连接的所有客户端提供传送服务。

在群集内，服务可用性取决于代理能否共享有关目的地和长期订户的信息。如果某个群集代理发生故障，则此状态信息可能会失去同步。要防止这种可能的情况，可以将群集内的某个代理指定为主代理。主代理维护配置更改记录，以跟踪群集的持久性实体（目的地和长期订阅）的更改。此记录用于将此类更改信息传播到发生更改时处于脱机状态的代理。

图 4–1 群集体系结构

以下各节讨论如何在群集内传送消息以及如何配置和同步代理（即使一个或多个代理处于脱机状态）。

消息传送

在群集配置中，代理共享有关目的地和消息使用方的信息。每个代理都知道以下信息：

群集内所有物理目的地的名称、类型和属性
每个消息使用方的名称、位置和兴趣
上述信息的更新（删除、添加或重新配置）

这使每个代理都可以从自己直接相连的消息生成方将消息路由到远程消息使用方。生成方的本机代理与使用方的本机代理具有不同的职责：

生成方的本机代理负责保持和路由源自该生成方的消息、进行日志记录、管理事务以及处理来自使用方客户端的确认。
使用方的本机代理负责保持有关使用方的信息、将消息转发给使用方、让生成方的代理知道使用方是否仍可用以及消息是否已成功使用。

群集代理可以协同工作以最大限度地降低群集内的消息流量。例如，如果某个远程代理对于同一个主题目的地有两个完全相同的订阅，则消息将只通过线路发送一次。可以设置一个目的地属性以指定向本地使用方的传送优先于向远程使用方的传送，从而进一步减小流量。

如果要求客户端与代理之间的消息传送安全且经过加密，则可以对群集进行配置，以便在代理之间提供安全的消息传送。

目的地属性

为一个群集代理中的物理目的地设置的属性适用于群集内该目的地的所有实例；但是，由这些属性指定的一些限制会应用于整个群集，而其他属性则应用于单独的目的地实例。表 4–1 列出了可以为物理目的地设置的属性并指定了它们的适用范围。

表 4–1 群集代理中物理目的地的属性


属性名	范围
`maxNumMsgs`	每个代理。因此，通过将生成方分布在一个群集中，可以提高对未使用消息的总数的限制。
`maxTotalMsgBytes`	每个代理。因此，通过将生成方分布在一个群集中，可以提高为未使用消息保留的总内存的限制。
`lmitBehavior`	全局
`maxBytesPerMsg`	每个代理
`maxNumProducers`	每个代理
`maxNumActiveConsumers`	全局
`maxNumBackupConsumers`	全局
`consumerFlowLimit`	全局
`localDeliveryPreferred`	全局
`isLocalOnly`	全局
`useDMQ`	每个代理

群集和目的地

无论目的地是管理员创建的、自动创建的还是临时的，都会影响该目的地在群集内的传播方式以及在连接失败或代理发生故障时该目的地的处理方式。以下各节将详细考察几个使用案例，以决定目的地的创建时间和目的地的复制方式。这些案例包括：

使用回复模型生成消息并放入队列

下图显示客户端生成消息并放入队列以及使用回复模型时，目的地的创建和复制方式。

图 4–2 在群集中复制目的地：使用回复的队列

管理员创建物理目的地 QW。创建时，队列在整个群集内复制。
生成方 ProdQW 向队列 QW 发送一条消息，并使用回复模型将回复定向到临时队列 TempQ1W。（应用程序创建临时目的地并添加使用方时，系统会创建和复制临时队列。）
本机代理 BrokerW 保持发送到 QW 的消息并将消息路由到第一个符合该消息选择标准的活动使用方。根据哪个使用方准备好接收该消息，将消息传送到使用方 C1QW（位于 BrokerX 上）或使用方 C2QW（位于 BrokerZ 上）。接收该消息的使用方会将回复发送到目的地 TempQ1W 。

生成消息并放入自动创建的目的地

下图显示生成方向不存在且必须自动创建的目的地发送消息时，目的地的创建和复制方式。

图 4–3 在群集中复制目的地：自动创建的目的地

生成方 ProdAutoQY 向代理中不存在的目的地 AutoQY 发送一条消息。
代理保持该消息并创建目的地 AutoQY。

自动创建的目的地不会自动在群集内复制。只有当某个使用方选择从队列 AutoQY 接收消息时，该使用方的本机代理才创建目的地 AutoQY 并将这些消息传递到该使用方。当一个使用方创建自动创建的目的地时，该目的地将在群集内复制。在本示例中，使用方 CAutoQY 创建目的地时就会复制该目的地。

发布到主题目的地

下图显示客户端将消息发布到管理员创建的主题目的地时，目的地在群集中的创建和复制方式。

图 4–4 在群集中复制目的地：发布到主题

管理员创建物理主题目的地 TY。管理员创建的目的地 TY 会在使用之前在代理群集内复制。
发布者 PubTY 向主题 TY 发送一条消息。
本机代理 BrokerY 保持发布到 TY 的任何消息，并将这些消息路由到所有符合该消息选择标准的主题订户。在本示例中，C1TY 和 C2TY 均订阅主题 TY。

在连接失败或代理发生故障时处理目的地

表 4–2 解释如何在群集内复制和删除不同种类的目的地。

表 4–2 在群集内处理目的地


目的地	传播和删除
管理员创建的	该目的地创建出来后，会在群集内传播，而且每个代理都永久存储有关该目的地的信息。当该目的地由管理员明确删除时，它会被销毁。如果有一个主代理，则会在主代理中存储有关创建和删除的记录，以使群集内的其他代理可以同步状态信息。
临时	该目的地创建出来后，会在群集内传播。如果允许与临时目的地关联的使用方重新连接，则该目的地将永久存储在使用方的本机代理中。否则，该目的地将永远也不会存储。如果该使用方的连接断开，则该目的地将从所有代理中删除。如果该使用方的本机代理崩溃，并且允许该使用方重新连接，则与该使用方关联的临时目的地将受到监视。如果使用方客户端在特定的时间段内未重新连接，则会假定该客户端出现故障，该目的地将被删除。
自动创建	创建生成方时，如果目的地不存在，则会在生成方的本机代理中创建一个目的地。为不存在的目的地创建使用方时，有关该使用方和目的地的信息会在群集内传播。自动创建的目的地可以由管理员明确删除，也可以在以下情况下由每个代理自动删除：在给定的时间段内没有使用方或消息。当代理重新启动时，并且没有该目的地的消息。

群集配置

要在启动时在群集代理之间建立连接，必须为每个代理传送其他所有代理（包括主代理，如果有）的主机名和端口号。这些信息是通过一组 群集配置属性来指定的，对于群集内的所有代理，这些属性应该是相同的。虽然可以为每个代理分别指定配置属性，但这种方法容易出错，并且容易导致群集配置出现不一致的情况。因此，建议您将所有配置属性都集中放在一个 群集配置文件中，供每个代理在启动时引用。这样，就可以确保所有代理共享相同的配置信息。

有关群集配置属性的详细信息，请参见《Sun Java System Message Queue 3.7 UR1 管理指南》中的“群集配置属性”。

注 –

虽然群集配置文件原本是用来配置群集的，但也可以方便地使用它来存储群集内的所有代理共有的其他属性。

群集同步

每次更改群集的配置时，有关更改的信息都会自动传播到群集内的所有代理。发生以下某个事件时，会更改群集配置：

在群集的某个代理中创建或销毁目的地。
目的地的属性发生更改。
消息使用方向它的本机代理进行注册。
消息使用方与它的本机代理断开连接（无论是明确断开，还是由于客户端、代理或网络故障而断开）。
消息使用方建立了对某个主题的长期订阅。

有关这些更改的信息会立即传播到群集内发生更改时处于联机状态的所有代理。但是，发生更改时，处于脱机状态的代理（例如，已崩溃的代理）不会收到更改通知。为了给脱机代理提供该信息，Message Queue 维护群集的配置更改记录，其中记录了已创建或已销毁的所有持久性实体（目的地和长期订阅）。当脱机代理恢复为联机状态时（或向群集添加新代理时），会查阅此记录以获取有关目的地和长期订户的信息，然后与其他代理交换有关当前活动的消息使用方的信息。

群集内的某个代理被指定为 主代理，该主代理负责维护配置更改记录。因为在没有主代理的情况下其他代理无法完成初始化，所以应该始终首先启动群集内的主代理。如果主代理处于脱机状态，则将无法在整个群集内传播配置信息，因为其他代理无法访问配置更改记录。在这些情况下，如果尝试创建、重新配置或销毁目的地或长期订阅，或者尝试执行某个相关的操作（例如，重新激活长期订阅），将发生异常。（但是，非管理消息传送仍然可以正常进行。）主代理和配置更改记录的使用是可选的。只有当群集配置发生更改或代理发生故障之后群集的同步非常重要时，才有必要使用它们。

第 4 章 代理群集