服务总线队列、主题和订阅

Azure 服务总线支持可靠消息队列和持久发布/订阅消息。 服务总线中构成消息传送功能核心的消息传送实体是队列、主题和订阅。

本文介绍这些核心消息传送实体及其优点，以及何时在应用程序体系结构中使用每个实体。

在队列和主题之间进行选择

下表总结了队列和主题之间的主要差异，以帮助你为方案选择正确的消息传送实体。

队列

队列为一个或多个竞争使用方提供先入先出 (FIFO) 消息传递方式。 也就是说，接收方通常会按照消息添加到队列中的顺序来接收并处理消息。 并且每条消息仅由一个消息使用方接收并处理。

服务总线队列的示意图，显示了消息从发送方流向队列，然后再流向接收方。

使用队列的好处

创建队列

可以使用下列选项之一创建队列：

• Azure 门户
• PowerShell
• CLI
• Azure 资源管理器模板（ARM 模板）

然后，使用以编程语言编写的客户端发送和接收消息。编程语言包括以下语言：

• C#
• Java
• Python
• JavaScript

接收模式

可以指定两种不同的可供使用者用来从服务总线接收消息的模式。

接收和删除模式

当服务总线收到来自使用者的请求时，它将消息标记为已使用，并将其返回到使用者应用程序。 此模式是最简单的模型，最适合应用程序在发生故障时无法容忍处理消息的情况。

如果在处理消息之前使用者崩溃，则消息会丢失，因为服务总线已将其标记为已使用。 此过程通常称为“至多一次”处理。

窥视锁模式

接收操作将分为两个阶段，从而支持那些无法容忍消息丢失的应用程序。

1. 查找要使用的下一条消息， 将其锁定 以防止其他使用者接收它，然后将消息返回到应用程序。
2. 在应用程序处理完该消息后，它会请求服务总线服务完成接收过程的第二阶段。 然后，该服务将消息标记为“已使用”。

在窥视锁定模式下处理失败：

• 放弃：如果应用程序无法处理消息，它可以请求服务总线 放弃 该消息。 服务总线解锁消息，使其能够再次接收。
• 锁定超时：如果应用程序在锁定超时到期前无法处理消息，服务总线会解锁消息，并使消息再次可用。
• 应用程序崩溃：如果应用程序在处理消息后崩溃，但在完成消息之前，服务总线在应用程序重启时重新传送消息。 此过程通常称为“至少一次”处理。

如果方案不容许重复处理，请在应用程序中添加其他逻辑来检测重复项。 有关详细信息，请参阅重复检测，该检测称为“恰好一次”处理。

主题和订阅

队列允许单个使用方处理消息。 与队列不同，主题和订阅以“发布和订阅”模式提供一对多的通信形式。 这对于扩展到大量接收方而言十分有用。 每个发布的消息均可用于向该主题注册的每个订阅。 发布方将消息发送到主题，一个或多个订阅服务器将接收该消息的副本。

发布方将消息发送到主题的方式与将消息发送到队列的方式相同。 但使用方不会直接从主题接收消息。 相反，使用方从该主题的订阅接收消息。 主题订阅类似于接收发送至该主题的消息副本的虚拟队列。 使用方从订阅接收消息的方式与从队列接收消息的方式相同。 队列的消息发送功能直接映射到主题，而其消息接收功能映射到订阅。 另外，此功能意味着订阅支持本部分前面所述的有关队列的相同模式：竞争使用者、临时分离、负载调节和负载均衡。

订阅筛选器

订阅可以定义他们希望从主题接收的消息。 这些消息采用一个或多个命名订阅规则的形式指定。 每个规则包含一个选择特定消息的筛选条件，还可包含一个对所选消息进行批注的操作。 默认情况下，主题的订阅接收发送到该主题的所有消息。 订阅具有一个初始默认规则，该规则带有一个真筛选条件，允许将所有消息选择到订阅中。 默认规则没有关联的操作。 可以使用订阅上的规则和操作定义筛选条件，以便订阅仅接收发送到主题的消息子集。

有关筛选器的详细信息，请参阅 筛选器和作。

创建主题和订阅

创建主题与创建队列类似，如前一部分中所述。 可以使用下列选项之一创建主题和订阅：

• Azure 门户
• PowerShell
• CLI
• ARM 模板

然后，使用以编程语言编写的客户端将消息发送到主题并从订阅接收消息。编程语言包括以下语言：

• C#
• Java
• Python
• JavaScript

规则和操作

在许多情况下，必须以不同方式处理具有特定特征的消息。 若要启用此处理，可以将订阅配置为查找具有所需属性的消息，然后对这些属性执行某些修改。 虽然服务总线订阅可看到发送到主题的所有消息，但你只能将这些消息的一个子集复制到虚拟订阅队列。 可使用订阅筛选器完成此筛选。 此类修改称为筛选器操作 。 创建订阅后，你可以提供对消息属性进行操作的筛选表达式。 这些属性可以是系统属性（例如“标签”），也可以是自定义应用程序属性（例如“StoreName” 。）SQL 筛选器表达式在此示例中为可选。 如果没有 SQL 筛选器表达式，会对该订阅的所有消息执行在订阅上定义的任何筛选器操作。

有关完整的工作示例，请参阅 GitHub 上的 TopicFilters 示例。 有关筛选器的详细信息，请参阅主题筛选器和操作。

Java 消息服务 (JMS) 2.0 实体

以下实体可通过 Java 消息服务 (JMS) 2.0 API 进行访问。

• 临时队列
• 临时主题
• 共享持久订阅
• 非共享持久订阅
• 共享非持久的订阅
• 不可共享的非持久性订阅

详细了解 JMS 2.0 实体和如何使用它们。

快速实体

Express 实体专为高吞吐量和减少延迟的方案而创建。 使用快速实体时，如果消息发送到队列或主题，则不会立即存储到消息存储库中。 相反，消息最初会缓存在内存中。 实体中保留的消息在延迟后写入到消息存储中，此时它们会受到保护，以防止由于服务中断而丢失。

在常规实体中，任何运行时操作（例如Send，Complete，Abandon，Deadletter）会首先保存到存储区中，只有在操作被确认成功后才会通知客户端。 在 express 实体中，运行时操作首先向客户端确认操作成功，然后才延迟持久保存到存储区中。 因此，当计算机重新启动或发生硬件问题时，一些确认的运行时作可能根本不会持久保存。 在这种情况下，客户端通过“快速实体”获得较低的延迟和更高的吞吐量，代价是可能会出现数据丢失和/或消息重新传送的情况。

后续步骤

尝试使用所选语言的示例：

• 适用于 .NET（最新）的 Azure 服务总线客户端库示例
• 适用于 Java（最新）的 Azure 服务总线客户端库示例
• 适用于 Python 的 Azure 服务总线客户端库示例
• 适用于 JavaScript 的 Azure 服务总线客户端库示例
• 适用于 TypeScript 的 Azure 服务总线客户端库示例

有关使用旧版 .NET 和 Java 客户端库的示例，请使用以下链接：

• 适用于 .NET（旧版）的 Azure 服务总线客户端库示例
• 适用于 Java（旧版）的 Azure 服务总线客户端库示例