2

我试图找到一种方法来按照发送者发送消息的顺序处理消息，因为 NServiceBus 不保证消息将按特定顺序处理。

发送者是一个发布 createOrder 和 reviseOrder 命令的订单系统。发件人允许用户向同一订单提交多个修订，因此队列中可以同时存在修订 4 和修订 3。每个修订版都有一个修订版号和与之关联的原因代码，它驱动一些业务逻辑，因此我们不能忽略任何修订版或至少它的原因部分。

下面列出了我的一些想法 -

  1. 将修订号与目标记录一起存储。发件人在每个修订消息中发送他们的修订号。处理程序比较发送者和目标修订号，如果它们匹配，则更新记录，否则将消息放在队列的末尾。使用这种方法，如果版本 2 消息失败并进入错误队列，则版本 3 将永远不会被处理。

  2. 发件人在每条修订消息上发送所有修订的所有原因代码的历史记录。因此，如果修订 2 消息失败，修订 3 消息将包含所有原因代码。这些原因代码将记录在目标中，但可能不会出现与先前修订原因代码相关的任何业务逻辑。

我们如何针对这种情况进行设计？
还有关于如何处理失败的修订消息的任何想法？

一些指导真的很感激。

谢谢。

4

1 回答 1

9

开箱即用的关于 NserviceBus 的主要准则之一是您应该以一种顺序无关紧要的方式构建系统。之前说过我已经用 NSB 构建了一个有序的系统，我决定这样做：

  • 为所有消息添加序列号
  • 在接收器中检查序列号是最后看到的数字+ 1，如果没有抛出乱序异常
  • 启用二级重试（因此，如果它们出现故障，他们希望在收到正确消息后稍后再试）

这通常工作得很好，但是如果某些东西出现故障的时间太长并且需要手动干预来重新排序，有时事情会变得有点不正常。

在您的情况下，可能有更好的方法。鉴于您只想在对订单进行的修订中进行订购。我认为您可以以不需要订购交付的方式构建它。

  • 将修订号添加到您可以通过修订修改的所有字段
  • 仅当消息中的修订号 >= 数据库中的最后一个修订时才更新该字段

这有很多好处。

  • 它不依赖于订单
  • 它通过只要求接收方处理每条消息一次来减少负载
  • 如果单个消息出现问题，它不会停止所有内容，从而很好地处理错误。

但它有以下缺点：

  • 增加了数据库的复杂性
  • 它最终是一致的，如果您查看数据库，它可能只包含用户所做的一些编辑。
  • 如果 rev2 错误并且 rev3 被正确处理，则某些用户编辑将不存在，但有些将
于 2013-09-07T01:25:32.097 回答