Compartilhar via

使用多个命名空间使应用程序免受Service Bus中断和灾难的影响

任务关键型应用程序必须连续运行，即使是在计划外中断或灾难发生时。 针对数据处理资源灾难性中断的复原能力是许多企业的一项要求，某些情况下甚至是行业法规要求。

注意

Service Bus异地灾难恢复和异地复制可帮助你从大规模灾难中恢复，或者永久放弃失败的Azure区域，而无需更改应用程序配置。 有关这些功能以及如何在 Azure Service Bus 中实现可靠性和复原能力的详细信息，请参阅 Azure Service Bus。

如果无法使用 Geo-Disaster Recovery 或 Geo-Replication 来满足要求，则可以部署多个Service Bus命名空间。 本文介绍如何使用多个命名空间保护应用程序免受潜在的服务中断或灾难的影响。

复制类型

若要使用 Service Bus 标准层实现针对灾难的复原能力，可以使用 active 或 passive 复制。 如果队列或主题在数据中心中断期间必须保持可用状态，请在这两个命名空间中创建相同的实体。 实体可以共享相同的名称，因为它们存在于单独的命名空间中。 例如，可以在 contosoPrimary.servicebus.chinacloudapi.cn/myQueue 下访问主队列，而可以在 contosoSecondary.servicebus.chinacloudapi.cn/myQueue 下访问其辅助队列。

注意

active replication 和 passive replication 安装程序是常规用途概念，而不是Service Bus的特定功能。 复制逻辑（发送到 2 个不同的命名空间）存在于发送方应用程序中，而接收方必须具有用于检测重复项的自定义逻辑。

如果应用程序不需要永久的发送方到接收方通信，则应用程序可以实现持久的客户端队列，以防止消息丢失，并保护发送方免受任何暂时性Service Bus错误的影响。

主动复制

主动复制对于每个操作都使用这两个命名空间中的实体。 任何发送消息的客户端都会发送同一条消息的两个副本。 第一个副本发送到主要实体（例如 contosoPrimary.servicebus.chinacloudapi.cn/sales），该消息的第二个副本发送到辅助实体（例如 contosoSecondary.servicebus.chinacloudapi.cn/sales）。

客户端从两个队列接收消息。 如果接收方处理了消息的第一个副本，则第二个副本会被取消。 要取消重复的消息，发送方必须用唯一标识符标记每一条消息。 必须用同一标识符标记消息的两个副本。 可使用 ServiceBusMessage.MessageId 或 ServiceBusMessage.Subject 属性或自定义属性对消息进行标记。 接收方必须维护已接收的消息列表。

注意

主动复制方法会使操作数加倍，因此这种方法可能导致成本上升。

被动复制

在无故障的情况下，被动复制仅使用两个消息传送实体之一。 客户端将消息发送给活动实体。 如果针对活动实体的操作失败并返回错误代码，表明承载活动实体的数据中心可能不可用，则客户端将该消息的副本发送到备份实体。 此时活动实体和备份实体将互换角色。 发送方客户端会将旧的活动实体视为新的备份实体，并将旧的备份实体视为新的活动实体。 如果两次发送操作都失败，则两个实体的角色将保持不变并返回错误。

客户端从两个队列接收消息。 因为接收方可能接收同一条消息的两个副本，所以接收方必须取消重复消息。 可通过与主动复制中所述的相同方式取消重复消息。

一般来说，被动复制比主动重复更经济，因为在大多数情况下仅执行一个操作。 延迟、吞吐量和货币成本均与非复制场景相同。

使用被动复制时，在以下情况下可能丢失消息或接收两次消息：

  • 消息延迟或丢失：假定发送方将消息 m1 成功发送到主要队列，而该队列在接收方接收 m1 之前变为不可用。 发送方将后续消息 m2 发送给辅助队列。 如果主要队列是暂时不可用，则接收方会在该队列恢复可用后接收 m1。 发生灾难时，接收方可能永远不会收到 m1。
  • 重复接收：假定发送方将消息 m 发送到主要队列。 Service Bus成功处理 m，但无法发送响应。 发送操作超时后，发送方将向辅助队列发送 m 的一份相同副本。 如果接收方能够在主要队列变为不可用之前接收 m 的第一个副本，则接收方会在几乎同一时间接收 m 的两个副本。 如果接收方不能在主要队列变为不可用之前接收 m 的第一个副本，则接收方首先仅接收 m 的第二个副本，但会在主要队列变得可用后接收 m 的另一个副本。

.NET Core的Azure消息传送复制任务示例展示了命名空间之间的消息复制。

后续步骤

若要了解有关灾难恢复的详细信息，请参阅这些文章：

  • Last updated on