如何确保消息传输的可靠性

Question

我正在使用Azure服务总线来实现不同的有界上下文之间的消息通信。我很好奇人们使用什么技术来确保在一个bc中引发的域事件被另一个消费bc所接收。

例如，假设"orders“bc引发了一个"orderPlaced”事件，我如何确保“发货”bc接收到此事件。我知道2阶段提交在云中是不可取的，那么有什么可供选择的呢？如何减少正在下的订单，但在发生网络故障时未能将消息发送到服务总线？

我们欢迎你的想法。谢谢。

Answer 1

如果向服务总线队列发送BrokeredMessage并接收确认，则消息已成功存储在队列中。您不必担心消息在传输过程中会因为网络错误而死亡，因为您已经被告知该消息是持久化的。

您可以担心的是，服务总线队列会在一段时间内脱机，并且不可用。在中断期间，您的orderPlaced消息一开始就无法进入队列，您的发送逻辑也无法接收已经在队列中持久化的订单。

请注意，服务总线队列中断是短暂的，队列恢复并返回到正常服务。那时，您的配送应用程序可以耗尽现有消息的队列，您的订购应用程序可以再次插入orderPlaced消息。我不记得上一次看到我的服务总线队列下降是什么时候--这是一个罕见的事件。

如果你非常担心永远不会放弃一条信息，那就看看配对命名空间。基本上，这允许对备用队列进行故障转移，以便您可以在主服务器关闭时插入消息。自动检测检查，查看主队列何时恢复联机。当主服务器恢复联机时，虹吸进程将在中断期间插入到故障转移队列中的消息发送回主服务器。

编辑:发送时，即使您在QueueClient或MessagingFactory中有一个有效的服务总线队列连接，底层的服务总线队列仍然有可能像玻璃边的职业拳击手一样下降。在绝大多数情况下，这些错误都是短暂的。要处理它们，请设置RetryPolicy属性的MessagingFactory或QueueClient。从我头上看，我认为目前唯一可用的策略是RetryExponential策略。这将执行回退，将重试发送消息，直到用尽指定次数的尝试为止。这是处理服务总线队列连接中弹出的瞬态错误的简单方法。