订单很重要时缺少消息

Question

我正在处理从现场设备接收消息的情况。这些消息上印有序列号，我需要按原始顺序处理这些消息。很少有消息会丢失，但并非不可能，因此我需要一种机制来处理它。

我的实现是基于NServiceBus构建的，我正在利用“HandleCurrentMessageLater”功能将消息弹出到队列的后面，以防邮件被无序接收。

如果我最终收到序列中的下一条消息，那么这很有效，所以我可以处理积压。

在这种情况下，我有哪些选项来处理丢失的消息？我的第一个反应是实现某种老化算法，这会在一系列失败的尝试或类似事件之后增加序列号，但是必须这样做的复杂性有点过分。

有没有人遇到过类似的问题并且愿意分享他们如何解决它？

由于

Answer 1

在我看来，这是您需要从业务中输入的内容。是否有时间限制，之后可以假定该消息不可挽回地丢失？如果是这样，在这种情况下应采取的商业行动是什么？如果最终收到该消息但超时后会发生什么？

你可以用Saga实现的那种案例。如果消息到达并且不按顺序，那么您仍然会调用HandleCurrentMessageLater，但是您也会请求超时，以便在业务批准的超时后这些条件仍然为真，那么补偿操作可以运行，其余的可以处理备份的消息。

或者，替代解决方案也许是可能的。您说您需要按原始顺序处理邮件。您不会详细了解这对现实生活的影响，但这听起来像是一个高级别的业务要求，而不是技术要求。换句话说，这就是企业想要看到它的方式，但它不一定是它真正发生的方式。也许您可以正常处理有序消息，并增加一个值，指示收集的数据有效的序列号。如果消息无序到达，它们仍然可以进行软处理，但序列号不会增加。

所以基本上你收到消息1-5并正常处理它们。然后你收到7-10（已被跳过6）然后你处理它们，但ValidSequenceNumber仍然是5.然后当＃6到达时，你处理它，采取任何补偿动作来赶上，而ValidSequenceNumber现在是10. Saga也是实现这种逻辑的好人选。

Answer 2

使用NSB传奇时，David Boike有正确的答案。我想添加另一个选项。如果消息在很短的时间内产生，则设备可以使用NSB功能将多个逻辑消息批量处理成一个传输消息。只需使用Send的{​​{1}}或Publish重载即可获取多个消息参数。这些批次保证按顺序处理。

Answer 3

如果您确实需要所有可靠传递的消息并且您的传输通道不可靠，那么您需要一个确认和重传机制。这可能如下所示。

正常流程：

1. 发送消息后，客户端会临时存储该消息，以便能够在需要时重新发送。
2. 在成功进行传输后，服务器会向客户端发送确认消息，包括序列号。
3. 通过接收ACK，客户端会从其临时消息存储中删除相应的消息。

失信息：

1. 通过检测到无序条件，服务器向客户端发送重发消息，包括上次成功接收消息的序列号。
2. 客户端重新发送上一次收到的消息之后的所有消息。

这显然需要双向通信，从服务器到客户端的传输通道。

这个问题已经深入地解决了TCP协议，它保证了顺序传输。您可能想看一下TCP重传内部。