我试图找到一种按照发送者发送消息的顺序处理消息的方法，因为 NServiceBus 不保证消息将以特定顺序处理。
发送者是一个订单系统，它发布 createOrder 和 reviseOrder 命令。发送者允许用户向同一订单提交多个修订，因此队列中可以同时有修订 4 和修订 3。每个修订版都有一个修订版号和与之关联的原因代码，它们驱动一些业务逻辑，因此我们不能忽略任何修订版或至少是其中的原因部分。
下面列出了我的一些想法 -
将修订号与目标记录一起存储。发送者在每条修订消息中发送其修订号。处理程序比较发送者和目标修订号，如果它们匹配，则更新记录，否则消息将被放置在队列的末尾。使用这种方法，如果修订版 2 消息失败并进入错误队列，则修订版 3 将永远不会被处理。
发件人发送每条修订消息上所有修订的所有原因代码的历史记录。因此，如果修订版 2 消息失败，修订版 3 消息将包含所有原因代码。这些原因代码将记录在目标中，但与先前修订原因代码关联的任何业务逻辑可能不会发生。
针对这种场景我们该如何设计呢？
还有关于如何处理失败的修订消息的任何想法吗？
非常感谢一些指导。
Thanks.
关于 NserviceBus 的开箱即用的主要准则之一是，您应该以顺序无关紧要的方式构建系统。话虽如此，我之前已经与 NSB 构建了一个有序系统，以下是我决定这样做的方式：
- 为所有消息添加序列号
- 在接收器中检查序列号是最后看到的数字+1，如果不是则抛出乱序异常
- 启用二级重试（因此，如果它们出现故障，他们将在收到正确的消息后再次尝试）
这通常工作得很好，但有时如果某些东西出现故障时间太长并且需要手动干预来重新排序，那么有时会有点不正常。
在您的情况下可能有更好的方法。鉴于您只想在按订单进行的修订中订购。我认为你可以用一种不需要有序交付的方式来构建它。
- 将修订号添加到您可以使用修订版进行修改的所有字段
- 仅当消息中的修订号 >= 数据库中的最后一个修订版时才更新字段
这有很多好处。
- 它不依赖于顺序
- 它只要求接收者处理每条消息一次，从而减少负载
- 如果单条消息出现问题，它不会停止所有事情，从而可以很好地处理错误。
但它有以下缺点：
- 增加了数据库的复杂性
- 它最终是一致的，如果您查看数据库，它可能只包含用户所做的一些编辑。
- 如果 rev2 错误并且 rev3 处理正确，则某些用户编辑将不会出现，但有些会出现
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
