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

已完成

构成服务总线消息传送功能核心的消息传送实体包括队列、主题和订阅以及规则/操作 。

队列

队列为一个或多个竞争使用方提供先入先出 (FIFO) 消息传递方式。 也就是说,接收方通常会按照消息添加到队列中的顺序来接收并处理消息。 并且每条消息仅由一个消息使用方接收并处理。 由于消息持久地存储在队列中,因此生产者(发送方)和使用者(接收方)不必同时处理消息。

相关的优点是“负载分级”,它允许创建方和使用方以不同速率发送和接收消息。 在许多应用程序中,系统负载随时间而变化。 但是,每个工作单元所需的处理时间通常为常量。 使用队列在消息创建方与使用方之间中继意味着,消费应用程序只需能够处理平均负载而非峰值负载。

使用队列在消息创建方与使用方之间中继可在各组件之间提供固有的松散耦合。 由于创建方和使用方互不相识,因此,可升级使用方,而不会对创建方产生任何影响。

可以使用 Azure 门户、PowerShell、CLI 或资源管理器模板创建队列。 然后,使用以 C#、Java、Python 和 JavaScript 编写的客户端发送和接收消息。

接收模式

你可以指定服务总线接收消息时的两种不同模式:“接收并删除”或“扫视锁定”。

接收并删除

在此模式下,当服务总线收到来自使用者的请求时,它会将该消息标记为“已使用”,并将其返回给使用者应用程序。 此模式是最简单的模型。 它最适合应用程序允许在出现故障时不处理消息的方案。 例如,可以考虑这样一种情形:使用者发出接收请求,但在处理该请求前发生了故障。 由于服务总线将消息标记为“已使用”,因此应用程序会在重启后开始使用消息。 它会丢失在发生故障前使用的消息。

速览锁定

在此模式下,接收操作分成了两步,从而有可能支持无法容忍遗漏消息的应用程序。

  1. 查找要使用的下一条消息,将其锁定以防其他使用者接收它,然后,将该消息返回到应用程序。

  2. 在应用程序处理完该消息后,它会请求服务总线服务完成接收过程的第二阶段。 然后,该服务将消息标记为“已使用”。

如果应用程序出于某种原因无法处理该消息,它可以请求服务总线服务放弃 该消息。 服务总线会解锁该消息并使其能够再次被同一个使用者或其他竞争使用者接收。 其次,有一个与该锁定关联的超时。 如果应用程序无法在锁定超时期满前处理消息,服务总线会解锁消息,使其再次可供接收。

主题和订阅

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

此订阅可以使用更多筛选器来限制其想要接收的消息。 发布方将消息发送到主题的方式与将消息发送到队列的方式相同。 但使用方不会直接从主题接收消息。 相反,使用方从该主题的订阅接收消息。 主题订阅类似于接收发送至该主题的消息副本的虚拟队列。 使用方从订阅接收消息的方式与从队列接收消息的方式相同。

队列的消息发送功能直接映射到主题,而其消息接收功能映射到订阅。 另外,此功能意味着订阅支持本部分前面所述的有关队列的相同模式:竞争使用者、临时分离、负载调节和负载均衡。

规则和操作

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