Architecture 订单重要时缺少消息

我正在处理一种情况，即我从现场设备接收消息。这些信息已加盖序列号，我需要按照原始顺序处理这些信息。消息丢失是很少见的，但并非不可能，所以我需要一个to机制来处理它

我的实现是基于NServiceBus构建的，我正在利用“HandleCurrentMessageLater”功能，在消息接收顺序错误的情况下将消息弹出到队列的后面

如果我最终接收到序列中的下一条消息，这样我就可以处理积压工作，那么这种方法很有效

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

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

---

谢谢

在我看来，这是您需要从业务部门获得的信息。是否有一个时间限制，在该时间限制之后，可以认为该信息将不可撤销地丢失？如果是，在这种情况下应该采取什么商业行动？如果在超时后最终收到该消息，会发生什么情况

那些你可以用传奇故事来实现的案例。如果消息到达且顺序不正确，则稍后仍将调用HandleCurrentMessage，但也会请求超时，以便在业务批准的超时后，如果这些条件仍然为真，则可以运行补偿操作，并处理其余备份的消息

或者，可能会有另一种解决方案。你说过你必须按原来的顺序处理这些信息。您不会深入了解这一点对现实生活的影响，但这听起来像是一个高级业务需求，而不是一个技术需求。换句话说，这就是企业希望看到它的方式，但它不一定是它真正发生的方式。也许您可以正常处理顺序消息，还可以增加一个值，该值指示收集的数据对哪个序列号有效。如果消息按顺序到达，它们仍然可以进行软处理，但序列号不会增加

---

所以基本上你会收到1-5条信息，并正常处理它们。然后您收到7-10（跳过了6个）并处理它们，但ValidSequenceNumber仍然是5。然后，当#6到达时，您处理它，采取任何补偿措施以赶上，此时ValidSequenceNumber为10。Saga也可以很好地实现这种逻辑。

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

正常流量：

发送消息后，客户端临时存储消息，以便在需要时能够重新传输

在sequence传输成功后，服务器向客户端发送确认消息，包括序列号

接收ACK后，客户端从其临时消息存储中删除相应的消息

丢失的消息：

在检测到顺序错误的情况下，服务器向客户端发送一条重新传输消息，包括最后成功接收的消息的序列号

客户端重新发送上次接收的消息之后的所有消息

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

---

对于保证顺序传输的TCP协议，这一问题得到了深入的解决。您可能想看看TCP重传的内部结构。

David Boike在使用NSB传奇时给出了正确的答案。我想添加另一个选项。如果在短时间内生成消息，则设备可以使用NSBs功能将多个逻辑消息批处理为一条传输消息。只需使用

IBus

的

Send

或

Publish

重载即可，该重载接受多个消息参数。这些批处理保证按顺序处理。

如果有一条消息丢失，是否希望所有后续消息最终都失败？我需要接受消息在某个点丢失的事实，并处理我所拥有的数据。我们正在处理跟踪信息，因此我们需要在任何情况下限制数据丢失。感谢Bernd，我们有这样的机制。但在极端情况下，我们仍可能失去一个信息。例如，如果设备上发生错误，消息根本不发送。很多事情都可能导致这种情况，例如设备的总功率损失等。多亏了，我们正在按原样批处理消息，但是不可能按特定顺序批处理所有消息。信息是经过长时间收集的，我们需要在信息可用时对其进行处理。这是一项业务要求。谢谢大卫。我决定使用更手动的方法来报告这种情况，这将允许我暂时手动修复它。我想知道在我安装自动机制之前，它发生的频率有多高，更重要的是为什么会发生。