问题标签 [ordered-delivery]

使用 WCF netMSMQbinding 时是否可以保证有序交付？

我们在同一个队列中放置一个插入命令，然后是多个更新命令，有时其中一个更新会超过插入。

添加大量日志后，很明显它们以正确的顺序添加到队列中，并以不同的顺序进行处理。

我已经设法谷歌了几篇文章，指出这种行为是预期的，但似乎必须可以将其配置为以某种方式订购。

我们的队列是事务性的，所以我不认为在目的地添加序列号和重新排序会起作用，因为这会失去事务性

如果我添加属性[DeliveryRequirements(RequireOrderedDelivery=true, QueuedDeliveryRequirements=QueuedDeliveryRequirementsMode.Require)]，我会收到以下错误：

合同“IService”上的 DeliveryRequirementsAttribute 指定了 NotAllowed 的 QueuedDeliveryRequirements 值。但是，此合同的配置绑定指定它确实支持排队交付。此合同不得使用排队绑定。

我不知道为什么会出现此错误，因为一切“似乎”都设置正确。我还没有找到任何确认 MSMQ 允许此设置，因为它似乎是 WS-RM 设置，并且 AFAIK netMSMQBinding 不支持 WS-RM。

我们有一个 BizTalk 应用程序，其中输入消息的顺序非常重要并且必须保持，这意味着它们必须以相同的顺序输出。通常订购的交货会在这里解决问题。

但是，我读到只有当您将接收位置直接连接到发送端口时，才能保证有序交付。在您使用编排的那一刻，订单交付不再得到保证。有没有办法解决或解决这个问题？因为这种方式破坏了我们的整个应用程序，我们已经为此工作了几个月。

我从微软那里读到了一个解决方法，他们使用了一个带有计数器的额外字段，并且他们使用了一个检查计数器的结束编排。但这对我们来说现在要做的工作太多了。因此，这项工作是行不通的。另外，并非所有消息都被翻译，这会在我们的流程中造成漏洞，而且并非所有消息都来自同一来源，这使得这项工作无论如何都毫无用处。

还有其他想法吗？

另一个订购的交付问题。

我们有一个编排，它绑定到一个发送端口，该端口已下令交付为真。另一个发送端口也通过过滤接收这些消息，该端口也有顺序发送。

现在由于某种原因，当有多个端口使用该消息并且其中一个端口直接绑定时，只有一个端口正在使用。我的意思是不是两个端口都提供输出。

如果我取消登记它始终输出的端口之一，这两种方式都有效。

我们曾经有两个端口，这两个端口都使用过滤器，这有效，但我们不得不将一个更改为直接端口，从那时起问题就出现了。BizTalk 的端口选择也是非常随机的，因为在我们的服务器上，它例如选择端口 A，而当我在本地计算机上重新创建相同的问题时，它例如选择端口 B。

这是一个奇怪的问题，我们不知道可能是什么原因。

我有一个主要编排负责处理消息车队的情况。这些消息属于一组客户，编排将在消息进入时读取这些消息，并且对于它找到的每个新客户 ID，它将启动一个新的编排，负责处理特定客户的消息。我必须在消息进入时保留它们的顺序，因此新创建的编排应该处理它拥有的消息并等待来自主编排的其他消息。

尝试了不同的方法来解决这个问题，但未能成功实施。我想听听您对如何做到这一点的意见。

谢谢。

这是场景：

2 台机器：“机器 A”和“机器 B”。

假设它们对应的 IP 地址是 192.168.0.100（对于 A）和 192.168.0.200（对于 B）。两台机器上都安装了 MSMQ，在 Windows Server 2008 上。

机器A

已配置以下队列：private$\aaa、事务性。

该队列有一个消费者，它包装ReadMSMQ 事务中的每个操作，并且仅从“当前”消息中读取（即，不使用游标操作）。

机器 B

有一个将消息发送到的应用程序FormatName:direct=os:192.168.0.100\private$\aaa。每条Send消息都包装在一个 MSMQ 事务中，带有（C# 中的代码）：
TimeToReachQueue = Message.InfiniteTimeout
和
TimeToBeReceived = Message.InfiniteTimeout

还有……问题

在这种场景和配置下private$\aaa，是从 B 发送到 A 的消息：

1. 交付一次？我的意思是，我是否必须在机器 A 上的消费者应用程序中确保“当前”消息实际上是“新的”（也就是说，之前没有处理过）？还是 MSMQ 本身会处理这个问题？我知道这听起来有点傻，因为这是一个队列，对吧？！但是我找不到一个具体的参考资料声称这些消息是有序的。我见过这样的说法，但不是来自微软官方资源。
2. 为了？我的意思是，是否有可能M1由于网络问题，无法从 B 向 A 发送消息，然后，也许网络恢复正常，并且以下消息，M2成功发送到机器 A？

非常感谢！

我们的活动工作流程是这样工作的。

发布系统 --> 事件网格 --> Azure Function (Durable) --> 服务总线 --> 消费应用

现在对于一个新要求，我们需要维护事件/消息的顺序，因此基于事件网格首先接收到的任何内容，消费应用程序应该以相同的顺序接收它。

我们可以在事件网格、函数和服务总线中做些什么来维持这个顺序？

注意：中间使用 Azure Function 通过调用 API 来获取有关事件的详细信息。