如何保证消息传输可靠-ASB
How to ensure that message transmission is reliable - ASB
我正在使用 Azure 服务总线在不同的限界上下文之间实现消息通信。我很好奇人们使用什么技术来确保在一个 bc 中引发的域事件保证被另一个消费 bc 接收。
例如，假设 "orders" bc 引发了一个 "orderPlaced" 事件，我如何确保该事件被 "shipping" bc 接收到。我知道在云中不建议使用 2 阶段提交，那么有什么选择呢？如何在网络故障的情况下缓解已下订单但无法将消息发送到服务总线的情况？
欢迎提出想法。谢谢。
如果您将 BrokeredMessage 发送到服务总线队列并收到确认，则消息已成功存储在队列中。在得知消息已保存后，您不必担心消息会因网络错误而在传输过程中消失。
您可以担心的是服务总线队列在一段时间内掉线并且不可用。在中断期间，您的 orderPlaced 消息将无法首先进入队列，并且您的运输逻辑将无法接收已保存在队列中的订单。
请注意，服务总线队列中断是暂时的，队列会恢复并 returns 到正常服务。那时，您的送货应用程序可能会排空现有消息队列，而您的订购应用程序可能会再次插入 orderPlaced 消息。我实际上不记得上次看到我的一个服务总线队列出现故障是什么时候了——这是一个罕见的事件。
如果您非常担心永远不会丢弃一条消息，请查看 paired namespaces。基本上，这允许故障转移到备用队列，以便您可以在主队列关闭时插入消息。自动检测检查您的主队列何时恢复在线。一旦主服务器恢复联机，虹吸进程会将中断期间插入故障转移队列的消息吸回主服务器。
编辑： 发送时，仍然有可能即使您在 QueueClient 中 拥有 有效的服务总线队列连接或MessagingFactory，底层的服务总线队列就像一个玻璃下巴的职业拳击手一样崩溃了。绝大多数时候，这些错误是暂时的。要处理它们，请设置 MessagingFactory 或 QueueClient 的 RetryPolicy 属性。在我的脑海中，我认为目前唯一可用的策略是 RetryExponential 策略。这将执行退避，重试发送消息，直到用完指定的尝试次数。这是处理服务总线队列连接中弹出的暂时性错误的简单方法。
我正在使用 Azure 服务总线在不同的限界上下文之间实现消息通信。我很好奇人们使用什么技术来确保在一个 bc 中引发的域事件保证被另一个消费 bc 接收。
例如，假设 "orders" bc 引发了一个 "orderPlaced" 事件，我如何确保该事件被 "shipping" bc 接收到。我知道在云中不建议使用 2 阶段提交，那么有什么选择呢？如何在网络故障的情况下缓解已下订单但无法将消息发送到服务总线的情况？
欢迎提出想法。谢谢。
如果您将 BrokeredMessage 发送到服务总线队列并收到确认，则消息已成功存储在队列中。在得知消息已保存后，您不必担心消息会因网络错误而在传输过程中消失。
您可以担心的是服务总线队列在一段时间内掉线并且不可用。在中断期间，您的 orderPlaced 消息将无法首先进入队列，并且您的运输逻辑将无法接收已保存在队列中的订单。
请注意，服务总线队列中断是暂时的，队列会恢复并 returns 到正常服务。那时，您的送货应用程序可能会排空现有消息队列，而您的订购应用程序可能会再次插入 orderPlaced 消息。我实际上不记得上次看到我的一个服务总线队列出现故障是什么时候了——这是一个罕见的事件。
如果您非常担心永远不会丢弃一条消息，请查看 paired namespaces。基本上，这允许故障转移到备用队列，以便您可以在主队列关闭时插入消息。自动检测检查您的主队列何时恢复在线。一旦主服务器恢复联机，虹吸进程会将中断期间插入故障转移队列的消息吸回主服务器。
编辑： 发送时，仍然有可能即使您在 QueueClient 中 拥有 有效的服务总线队列连接或MessagingFactory，底层的服务总线队列就像一个玻璃下巴的职业拳击手一样崩溃了。绝大多数时候，这些错误是暂时的。要处理它们，请设置 MessagingFactory 或 QueueClient 的 RetryPolicy 属性。在我的脑海中，我认为目前唯一可用的策略是 RetryExponential 策略。这将执行退避，重试发送消息，直到用完指定的尝试次数。这是处理服务总线队列连接中弹出的暂时性错误的简单方法。