Apache Qpid Broker-J 第4章概念

最新推荐文章于 2023-07-29 10:44:24 发布

飞花丝雨

最新推荐文章于 2023-07-29 10:44:24 发布

阅读量505

点赞数

文章标签： java 消息队列

原文链接：https://qpid.apache.org/releases/qpid-broker-j-8.0.6/book/Java-Broker-Concepts.html

版权

第4章概念

原文链接：https://qpid.apache.org/releases/qpid-broker-j-8.0.6/book/Java-Broker-Concepts.html

4.1 概述

Broker包括许多实体。本节总结了每个实体的用途并描述了它们之间的关系。这些细节将在后续小节中进一步展开。

最重要的实体是虚拟主机（Virtualhost）。虚拟主机是一个独立的容器，在其中执行消息传递。虚拟主机存在于称为虚拟主机节点（virtualhost node）的容器中。一个虚拟主机节点只有一个虚拟主机。
译者注：一个Broker内可以有多个VirtualHost，每个VirtualHost可以是不同的类型，不同类型通常意味着不同的存储方式，例如，BDB，JDBC，JSON等。

Exchange 接受来自生产者应用程序的消息，并根据称为绑定的预先安排的标准将这些消息路由到一个或多个队列。 Exchange 是一个 AMQP 0-8、0-9、0-9-1、0-10 概念。它们的存在是为了产生有用的消息传递行为，例如扇出。当使用 AMQP 0-8、0-9、0-9-1 或 0-10 时，交换是将消息传入虚拟主机的唯一方式。使用 AMQP 1.0 时，应用程序可以使用交换器路由消息（以利用高级行为），也可以将消息直接发布到队列。
译者注：Exchange隶属于VirtualHost

队列（Queue）是命名实体，用于保存/缓冲消息以供稍后传递给消费者应用程序。
译者注：Queue隶属于VirtualHost

端口（Port）接受用于消息传递和管理的连接。 Broker 支持任意数量的端口。在连接消息时，用户指定一个虚拟主机名来指示它要连接到的虚拟主机。
译者注：Port隶属于Broker，一个Port根据其类型对应的实现，可以指定一个端口，多种协议或协议版本（例如 AMQP_1_0,HTTP），一个对应的身份验证插件对象实例，一组传输协议（例如TCP,SSL）。

身份验证提供程序（Authentication Providers）在用户连接以进行消息传递或管理时断言用户的身份。 Broker 支持任意数量的身份验证提供程序。每个端口都与一个身份验证提供程序相关联。当接收到新连接时，端口使用身份验证提供程序来断言用户的身份。

组提供者（Group Providers）提供提供用户分组的机制。 Broker 支持零个或多个组提供程序。

Access Control Provider 允许限制用户（或用户组）的能力。 Broker 可以有零个或一个访问控制提供程序。

密钥库（Keystores）提供证书存储库，并在 Broker 接受 SSL 连接时使用。可以定义任意数量的密钥库提供程序。密钥库与定义为接受 SSL 的端口相关联。

信任库（Truststores）提供信任存储库并用于验证对等点。可以定义任意数量的信任库提供。信任库可以与形成 SSL 连接的端口和其他实体相关联。

在使用高可用性功能时使用远程复制节点（Remote Replication Nodes）。它是同组中其他虚拟主机节点的远程表示。

在层次结构的这一点上，记录器（Loggers）负责为 Broker 生成日志。

这些概念将在接下来的页面中展开。下图还有助于将这些实体置于相关的上下文中。

图4.1 关键实体和消息流

图4.2 Broker主要实体结构

4.2 Broker

Broker 是系统中最外层的实体，记录了其下存在的持久实体。

4.3 虚拟主机节点

虚拟主机节点是虚拟主机的容器。它只有一个虚拟主机。

虚拟主机节点记录存在于虚拟主机节点下的持久实体（虚拟主机、队列、交换等）。

在使用 HA 时，多个Broker 的虚拟主机节点聚集在一起形成一个组。虚拟主机节点共同选举一个主节点。虚拟主机节点具有远程复制节点。一个远程复制节点对应于同组中的一个其他远程虚拟主机节点。

虚拟主机节点还为其虚拟主机提供初始配置。如何为虚拟主机指定初始配置在第 5.8 节“虚拟主机初始配置”中描述。

4.4 远程复制节点

仅用于 HA。远程复制节点是组中另一个虚拟主机节点的表示。

4.5 虚拟主机

虚拟主机是一个容器，在其中执行消息传递。虚拟主机是独立的；在一个虚拟主机中进行的消息传递独立于在另一个虚拟主机中进行的任何消息传递。例如，在一个虚拟主机中定义的名为 foo 的队列完全独立于另一个虚拟主机中名为 foo 的队列。

虚拟主机由名称标识，该名称必须在Broker范围内唯一。客户端在连接时使用该名称来标识他们希望连接的虚拟主机。

虚拟主机存在于虚拟主机节点中。

虚拟主机包括多个实体。本节总结了每个实体的用途并描述了它们之间的关系。这些细节将在后续小节中进一步展开。

Exchanges 是虚拟主机中的一个命名实体，它接收来自生产者的消息并将它们路由到匹配的队列。当使用 AMQP 0-8、0-9、0-9-1、0-10 时，Exchanges是将消息传入虚拟主机的唯一方式。使用 AMQP 1.0 时，生产者可以通过Exchanges或直接将消息路由到队列。

队列是命名实体，用于保存要传递给消费者应用程序的消息。

连接（Connections）代表从消息客户端到虚拟主机的实时连接。

会话（Session）表示消息的生产或消费的上下文。一个连接可以有许多会话。

消费者（Consumer）代表附加到队列的实时消费者。

记录器（Loggers）负责为这个虚拟主机生成日志。

下图描述了 Virtualhost 模型：

图4.3 虚拟主机主要实体模型

虚拟主机用存储来保存消息。

4.6 交换器（Exchange）

Exchange 是 Virtualhost 中的一个命名实体，它接收来自生产者的消息并将它们路由到 Virtualhost 中的匹配队列。

当使用 AMQP 0-8、0-9、0-9-1 或 0-10 时，交换器是将消息传入虚拟主机的唯一方式。使用 AMQP 1.0 时，应用程序可以使用交换器路由消息（以利用交换的路由行为），或者它可以直接路由到队列（如果需要点对点消息传递）。

服务器提供一组交换器类型，每种交换器类型实现不同的路由算法。有关这些交换器类型如何工作的详细信息，请参阅第 4.6.2 节“交换器类型”。

服务器预先声明了一些名称以“amq.”开头的交换器实例。这些在第 4.6.1 节“预先声明的交换器”中定义。

应用程序可以使用预先声明的交换器，也可以声明自己的交换器。虚拟主机内的交换器数量仅受资源限制。

当 Exchange 无法将消息路由到任何队列时的行为在第 4.6.4 节“无法路由的消息”中定义。

4.6.1 预定义交换器

每个 Virtualhost 预先声明以下交换：

amq.direct (direct类型)
amq.topic (topic类型)
amq.fanout (fanout类型)
amq.match (headers类型)

概念上的“默认交换器”始终存在，实际上是direct交换器的一个特殊实例，它使用空字符串作为其名称。所有队列在创建时使用队列名称作为绑定键自动绑定到它，并在删除时解除绑定。无法在此交换中手动添加或删除绑定。

4.6.2 交换器类型

支持以下 Exchange 类型：

Direct
Topic
Fanout
Headers

这些交换器类型在以下小节中描述。

4.6.2.1 Direct

Direct类型交换器规则是消息的路由Key与队列的绑定Key精确匹配。可以使用 JMS 消息选择器的绑定参数来指定其他过滤规则。

这种交换器类型通常用于实现点对点消息传递。以这种方式使用时，通常的约定是使用队列名称作为绑定Key。也可以将这种交换器类型用于多播，在这种情况下，相同的绑定Key与多个队列相关联。

图4.4 Direct交换器

上图说明了Direct类型交换器的操作。使用路由Key“myqueue”发布的黄色消息与对应于队列“myqueue”的绑定Key匹配，因此被路由到那里。使用路由Key“foo”发布的红色消息匹配表中的两个绑定，因此消息的副本被路由到“bar1”和“bar2”队列。

蓝色消息的路由Key不匹配绑定Key，因此该消息是不可路由的。它按照第4.6.4 节“不可路由消息”中的描述进行处理。

4.6.2.2 Topic

这种交换类型用于支持经典的发布/订阅范例。

主题交换器能够根据消息的路由Key和队列的绑定Key之间的通过通配符匹配将消息路由到队列。路由Key由一个或多个单词组成，每个单词以句号 (.) 分隔。模式匹配字符是 * 和 # 符号。 * 符号匹配单个单词，# 符号匹配零个或多个单词。

可以使用指定 JMS 消息选择器的绑定参数来指定其他过滤器规则。

以下三张图有助于解释主题交换的功能。

图4.5 主题交换器 - 主题名称精确匹配
上图说明了使用路由键“天气”发布消息。交换器将每条消息路由到绑定键与路由键匹配的每个绑定队列。

在所示的情况下，这意味着每个订阅者的队列都会收到每条黄色消息。

图4.6 主题交换器 - 主题名称分级模式匹配
上图说明了使用分级路由键发布消息。和之前一样，交换机将每条消息路由到每个绑定队列，其绑定密钥与路由密钥匹配，但由于绑定密钥包含通配符，因此上述通配符规则适用。

在所示的情况下，sub1 可以收到红色和绿色消息，因为“news.uk”和“news.de”匹配绑定键“news.#”。红色消息也发送到 sub2 和 sub3，因为它的路由键与“news.uk”和“*.uk”完全匹配。

黄色消息的路由键不匹配绑定键，因此该消息是不可路由的。它按照第 4.6.4 节“不可路由消息”中的描述进行处理。

图4.7 主题交换器 - JMS消息选择器匹配
上图说明了使用路由键“shipping”发布的带有属性的消息。

和以前一样，交换器将每条消息路由到每个绑定队列，其绑定键与路由键匹配，但由于已指定 JMS 选择器参数，针对每个匹配的消息评估表达式。只有消息头值或属性与表达式匹配的消息才会路由到队列。

在所示的情况下，sub1 可以收到黄色和蓝色消息，因为它们的属性“area”导致表达式“area in (‘Forties’, ‘Cromarty’)”评估为真。类似地，黄色消息也进入了 gale_alert，因为它的属性“speed”导致表达式“speed > 7 and speed < 10”评估为真。

紫色消息的属性导致没有表达式评估为真，因此消息是不可路由的。它按照第 4.6.4 节“不可路由消息”中的描述进行处理。

4.6.2.3 Fanout

扇出交换类型将消息路由到绑定到交换器的所有队列，而不管消息的路由键。

可以使用指定 JMS 消息选择器的绑定参数来指定过滤器规则。

图4.8 扇出交换器

4.6.2.4 Headers

头交换类型根据消息中的头属性将消息路由到队列。如果消息的标头属性满足绑定队列的绑定参数指定的 x 匹配表达式，则将消息传递到队列。

4.6.3 绑定参数

某些交换类型使用绑定参数来进一步过滤消息。

4.6.3.1 JMS Selector

绑定参数 x-filter-jms-selector 指定 JMS 选择器条件表达式。该表达式是根据消息头和消息属性名称编写的。如果表达式的计算结果为 true，则消息将路由到队列。直接、主题和扇出类型的交换器使用此参数。（这是对Qpid标准的扩展）

4.6.3.2 x-match

Headers类型的交换器使用绑定参数 x-match 。它用两个值指示在匹配过程中如何处理其余的名称值对。

all 意味着所有名称值对必须全部匹配要路由的消息的 headers 属性（即 AND 匹配）
any 意味着如果 headers 属性中的任何字段与参数表中的一个字段匹配（即 OR 匹配），则应路由消息

以下两种情况都算匹配：

绑定参数中的字段没有值并且消息头中存在同名字段；
绑定参数中的字段有值，消息头中同名字段的值与绑定参数中的值相同。

4.6.4 不可路由的消息

如果交易所无法将消息路由到任何队列，Broker 将：

如果使用 AMQP 1.0 协议，并且在交换器上设置了备用绑定，则消息将路由到备用绑定。如果在考虑备用绑定后消息仍然不可路由，则消息将被丢弃，除非发送链接已请求 REJECT_UNROUTABLE 目标功能，或者 Exchange 的 unroutableMessageBehaviour 属性设置为 REJECT。
如果使用 AMQP 0-10 协议，并且在交换器上设置了备用绑定，则消息将路由到备用。如果考虑了备用绑定后消息仍然不可路由，则丢弃该消息。
如果使用 AMQP 协议 0-8…0-9-1，发布者设置了强制标志并且没有路由时关闭连接特性还没有关闭连接，则消息返回给生产者。
否则，该消息将被丢弃。

4.7 队列（Queue）

4.7.1 队列类型

Broker 支持四种不同的队列类型，每种类型具有不同的交付语义。

标准队列 - 一个简单的先进先出 (FIFO) 队列
优先级队列 - 传递顺序取决于每条消息的优先级
排序队列 - 递送顺序取决于每条消息中排序键属性的值
LVQ队列 - 最后一个值队列，仅保留接收到的具有给定 LVQ 键值的最后（最新）消息

4.7.1.1 标准队列

一个简单的先进先出 (FIFO) 队列

4.7.1.2 优先级队列

在优先级队列中，队列中的消息按照消息中 JMS 优先级消息头确定的顺序进行传递。默认情况下，Qpid 支持 JMS 规定的 10 个优先级级别，优先级值 0 为最低优先级，9 为最高优先级。

如果需要，可以减少优先级的有效数量。

JMS 将默认消息优先级定义为 4。未指定优先级发送的消息使用此默认值。

4.7.1.3 排序队列

排序队列允许通过任意 JMS 消息属性的值来确定消息传递顺序。排序顺序是字母数字，属性值必须是 java.lang.String 类型。

发送到没有指定 JMS 消息属性的排序队列的消息将放在队列的头部。

4.7.1.4 LVQ队列

LVQ（或合并队列）是特殊队列，当新消息到达时，它们会自动丢弃任何具有相同键值的消息。键由任意 JMS 消息属性指定。

LVQ 的一个例子可能是队列代表证券交易所的价格：当您第一次从队列中消费时，您会获得每只股票的最新报价，然后当新价格出现时，您只会收到这些更新。

与其他队列一样，LVQ 可以被浏览或消费。浏览单个订阅者时，不会在收到消息时将其从队列中删除。这允许许多订阅浏览相同的 LVQ（即您不需要为希望接收 LVQ 内容的每个订阅者创建和绑定单独的 LVQ）。

发送到没有指定属性的 LVQ 的消息将正常传递并且永远不会被“替换”。

4.7.2 消息分组（Messaging Grouping）

代理允许应用程序将一系列相关消息分类为一个组。这允许消息生产者向消费者指示一组消息应被视为与应用相关的单个逻辑操作。

代理可以使用组标识来控制如何将来自给定组的消息分发给消费者的策略。例如，可以将代理配置为保证来自特定组的所有消息在多个消费者之间按顺序处理。

举例来说，假设我们有一个购物应用程序来管理虚拟购物车中的商品。用户可以将商品添加到他们的购物车中，然后改变主意并删除它。如果应用程序向代理发送添加消息，紧接着是删除消息，它们将按正确的顺序排队 - 添加，然后是删除。

但是，如果有多个消费者，则有可能一旦一个消费者获取了添加消息，不同的消费者就可能获取到删除消息。这允许并行处理两个消息，这可能导致“竞争”，即在添加操作之前不正确地执行删除操作。

4.7.2.1 消息分组

为了对消息进行分组，JMS 应用程序可以在发布消息时设置 JMS 标准头 JMSXGroupId 来指定组标识符。

或者，应用程序可以将特定的消息头指定为消息的组标识符。存储在该头字段中的组标识符应是由消息生产者设置的字符串值。来自同一组的消息将具有相同的组标识符值。消息消费者也必须知道标识标头的密钥。这允许消费者确定消息的分配组。

4.7.2.2 代理在消息分组中的作用

代理将对每个分组消息应用以下处理：

将接收到的消息排入目标队列。
通过检查消息的组标识符标头来确定消息的组。
在属于同一组的消息之间强制执行消费排序。消费排序意味着两件事之一，具体取决于队列的配置方式。
- 在默认模式下，一个组在该消费者的生命周期内被分配给一个消费者，并且代理会将组中的所有后续消息传递给该消费者。
- 在“共享组”模式下（它提供与 Qpid C++ Broker 相同的行为），broker 强制执行更宽松的保证，即组中所有当前未确认的消息都发送给同一个使用者，但使用的使用者可能会随着时间的推移而改变即使消费者不这样做。这意味着在任何给定时间只有一个消费者可以处理来自特定组的消息，但是如果消费者确认其获取的所有消息，则代理可能会将该组中的下一条待处理消息传递给不同的消费者。

消息的指定组头字段中缺少值的处理如下：

在默认模式下，消息指定组失败被视为希望消息根本不被分组。此类消息将分发给任何可用的消费者，而没有分组强加的排序保证。
在“共享组”模式下（其行为与 Qpid C++ Broker 相同），Broker 将没有组值的消息分配给“默认组”。因此，所有此类“未识别”消息都被代理视为同一组的一部分，将像任何其他组一样处理。此默认组的名称是“qpid.no-group”，但可以按如下详述对其进行自定义。

请注意，消息分组对队列浏览者没有影响。

请注意，不同的消息组不会相互阻止传递。例如，假设一个队列包含来自两个不同消息组的消息——比如组“A”和组“B”——并且它们被排入队列，使得“A”的消息在“B”的前面。如果“A”组的第一条消息正在被客户端消费，则剩余的“A”消息被阻塞，但“B”组的消息可供其他消费者消费——即使它位于队列中的“A”组“后面”。

4.7.3 强制所有消费者都是非破坏性的

当消费者附加到队列时，正常行为是发送给该消费者的消息仅由该消费者获取，当消费者确认它们时，消息将从队列中删除。

另一种常见模式是将所有消息发送到浏览者的队列“浏览者”，但不阻止其他消费者接收消息，并且在浏览者处理完消息后不将它们从队列中删除。这样的浏览者是“非破坏性”消费者的一个实例。

如果队列中的每个消费者都是非破坏性的，那么我们可以获得一些有趣的行为。在 LVQ 的情况下，队列将始终包含每个键的最新值。对于标准队列，如果每个消费者都是非破坏性的，那么我们的行为就像一个主题（每个消费者都会收到每条消息），除了只看到在创建消费者之后到达的消息之外，还包括所有未因 TTL 到期而删除的消息（或者，在 LVQ 的情况下，被同一键的较新值覆盖）。

可以创建一个队列来强制所有消费者都是非破坏性的。

4.7.3.1 使用max/min TTL 限制队列大小

对于 LVQ 以外的队列，只有非破坏性消费者可能意味着消息永远不会被删除，从而使队列不受约束地增长。为了防止这种情况，您可以使用设置队列的最大 TTL 的功能。为确保所有消息具有相同的 TTL，您还可以将最小 TTL 设置为相同的值。

可以使用 REST API 通过 HTTP 管理 UI 设置队列的最小/最大 TTL。属性名称是 minimumMessageTtl 和 maximumMessageTtl，TTL 值以毫秒为单位。

4.7.3.2 根据到达时间选择接收消息

没有破坏性消费者的队列将保留所有消息，直到它们因 TTL 而过期。可能的情况是消费者只希望接收在过去 60 分钟内发送的消息和任何新到达的消息，或者它可能只希望接收新到达的消息而不是队列中已有的消息. 这可以通过对到达时间使用过滤器来实现。

可以在消费者声明中使用特殊参数 x-qpid-replay-period 来控制消费者希望接收的消息。 x-qpid-replay-period 的值是消费者希望看到消息的时间（以秒为单位）。 x-qpid-replay-period 的值为 0 表示只应发送新到达的消息。 x-qpid-replay-period 的值为 3600 表示只应发送过去一小时内发送的消息以及任何新到达的消息。

使用 Qpid JMS AMQP 0-x 时，可以将x-qpid-replay-period参数放在声明消费者的地址中。

表4.1 使用 Qpid JMS AMQP 0-x 地址设置重放周期

Syntax	Example
Addressing	myqueue : { link : { x-subscribe: { arguments : { x-qpid-replay-period : ‘3600’ } } } }
Binding URL	direct://amq.direct/myqueue/myqueue?x-qpid-replay-period=‘3600’

4.7.3.3 设置默认过滤器

一个常见的情况可能是所需的默认行为是新附加的消费者只看到新到达的消息（即标准的类主题行为），但其他消费者可能希望从过去的某个时间点开始他们的消息流。这可以通过在队列上设置默认过滤器来实现，以便未明确设置x-qpid-replay-period的消费者获得默认值（在这种情况下，所需的默认值将为 0）。

可以使用名为 defaultFilters 的属性通过 REST API 设置为队列设置的默认过滤器。该值是从过滤器名称到类型和参数的映射。要将队列的默认行为设置为消费者仅接收新到达的消息，则应将此属性设置为值：

{ "x-qpid-replay-period" : { "x-qpid-replay-period" : [ "0" ] } }

如果所需的默认行为是每个消费者都应该看到最后一分钟到达的所有消息以及所有新消息，则该值需要为：

{ "x-qpid-replay-period" : { "x-qpid-replay-period" : [ "60" ] } }

4.7.4 在队列中保存消息

有时需要将消息放入队列后，直到满足某些外部条件才将其释放给消费者。

4.7.4.1 保持直到有效

目前，队列支持“保留”消息，直到（每条消息）提供的时间点。默认情况下，此支持未启用（因为它需要对进入队列的每条消息执行额外的工作。要启用支持，队列属性holdOnPublishEnabled 必须设置为真。启用后，将检查队列上的消息的标头（对于 AMQP 0-8、0-9、0-9-1 和 0-10 消息）或消息注释（对于 AMQP 1.0 消息）x-qpid-not-valid-before。如果此标头/注释存在并包含数值，它将被视为自 UNIX 纪元以来以毫秒为单位的时间点。在达到此时间之前，消息不会从队列中释放给消费者。

4.7.5 控制队列大小

可以在单个队列上配置溢出策略以限制队列大小。大小可以用最大字节数和/或最大消息数来表示。溢出策略定义达到任何限制时的队列行为。

支持以下溢出策略：

None - 队列无界且不应用容量限制。这是在未明确设置策略时隐式应用的默认策略。
Ring - 如果新到达的消息使队列超过限制，则从队列中删除消息，直到队列再次符合限制。删除消息时，最旧的消息首先被删除。对于优先级队列，删除优先级最低的最旧消息。
Producer Flow Control - 生产会话被阻塞，直到队列深度低于上下文变量 ${queue.queueFlowResumeLimit} 指定的恢复阈值（指定为限制值的百分比。默认值为 80%）。
Flow to Disk - 如果队列超出限制，新到达的消息将写入磁盘，并且消息在内存中的表示被最小化。 Broker 将透明地从磁盘检索消息，因为这是消费者或管理人员需要的。流到磁盘策略实际上并不限制队列的整体大小，仅限制内存占用的空间。 Broker 的其他 Flow to Disk 功能的运行完全独立于该队列溢出策略。
Reject - 当超出队列限制时，拒绝新到达的消息。

最大消息数或最大字节数的负值将禁用该限制。

当队列大小超出限制时，代理会记录操作日志消息。相关文档在表 C.6，“队列日志消息”。