【问题标题】:Azure Service Bus Topic-with paired or retryAzure 服务总线主题 - 配对或重试
【发布时间】:2018-04-05 14:34:39
【问题描述】:

我们在工作流管理器(审批流程)中使用 Azure 服务总线主题。无论如何,当我们将消息推送到服务总线主题时,我们不希望丢失/重复消息。现在有两种选择。 一个。仅使用重试 湾。仅使用配对服务总线而不重试。 由于我们不能同时使用两者,假设在消息推送期间,主服务总线不可用,然后将消息推送到配对的服务总线,当主服务总线可用时,自动将消息推送到主服务总线。但是如果我们使用重试,重试将尝试将消息推送到主服务总线,并且由于主服务总线不可用,消息也会发送到配对的服务总线。所以有机会处理重复的消息。

对于给定的问题陈述,将消息推送到服务总线的最佳选项是“a”还是“b”?

【问题讨论】:

  • 您指的是配对命名空间功能吗?如果是,则配对命名空间仅在主命名空间关闭时用作临时存储。它不用于处理消息。
  • @SeanFeldman 是的,配对命名空间,我知道它不会处理消息。一旦主服务总线可用,然后辅助推送消息到主服务总线。如果“a”和“b”最适合将消息推送到主服务总线?
  • 我不是 PairedNamespace 的忠实粉丝。会留下答案。

标签: azure-servicebus-topics


【解决方案1】:

这两种选择各有利弊。 使用配对命名空间,您可以在主命名空间关闭时继续发送消息。但不要上当。您仅在主命名空间关闭时存储这些消息。接收者不会重试它们。其他缺点包括

  • 没有很好的可测试性。
  • 成本增加(您发送到辅助服务器,然后从它取回以发送到主服务器)。
  • 故障转移到辅助服务器不是很直观。您必须在失败后手动重试消息。它不会自动切换到辅助命名空间。

查看post 了解更多详情。

通过重试方法,您可以获得简单性。还有一些你无论如何都需要做的事情。使用 Azure 服务总线操作可能会因间歇性异常而失败,无论如何您都应该重试。只有重试的缺点 - 不能防止中断。这就是为什么您可以使用自定义实现将它与辅助命名空间结合起来,但这是一个完全不同的温暖罐头。 NServiceBus 之类的库提供了一个自定义实现,您可以从中获得灵感。

【讨论】:

  • @SeanFeldman- 根据我的理解,在服务总线配对的情况下,我们没有从辅助服务器读取消息并推送到主服务器。一旦主服务器可用,消息会自动从配对服务传输到主服务器服务总线。参考docs.microsoft.com/en-us/azure/service-bus-messaging/…
  • 我不太明白你写的内容,但看起来你只是重复了我的回答:)
  • 我说的是这一点“增加的成本(你发送到辅助,从它取回发送到主)。”在配对的情况下,我们不需要从第二个检索消息并传递给第一个。它由配对的服务总线自动处理。
  • 您没有收到来自辅助命名空间的消息。 客户端在发生故障转移并且主命名空间再次在线后自动为您执行。
  • @SeanFeldman- 现在我们谈论的是同一件事。 :-) 让我们忽略成本。在区域 R1 中创建的主要服务总线和在配对区域 R2 中创建的第二个服务总线。假设主要服务中断 5-10 分钟。现在,最好的选择是什么?重试或主服务总线配置了配对区域服务总线?
猜你喜欢
  • 1970-01-01
  • 2019-07-25
  • 2018-10-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-06-05
  • 2022-01-05
相关资源
最近更新 更多