azure - Azure 服务总线是否可能创建了该消息的副本？

Question

我们在 Azure 服务总线上遇到了一些奇怪的行为，除了 Azure 中的一些错误之外，我们无法弄清楚如何解释。事情是这样的:

1. 我们已向 Azure 服务总线发送过一次消息
2. 发送消息的调用执行时间略长于一分钟，但仍然成功，并且此后消息收到良好
3. 大约半秒后出现了一条重复消息，其中 EnqueuedTimeUtc 和 SequenceNumber 与第一条消息不同，但内容和 MessageId 我们生成的

现在我们相当确定我们只对 SendMessage 进行了一次调用，因为我们在此之前进行了记录，并且还记录了所有收到的消息。

我们也不认为这是客户端库执行此操作，因为在总线上出现的这两条消息之间还发送了其他消息，并且我不认为客户端库在允许其他人在后台执行此操作的同时经过。但并不能 100% 确定这一点。这是我们发现发生的事情:

1. 第一条消息已发送
2. 完成操作大约需要 63 秒
3. 此后会发送一些其他消息
4. 发送第一条消息后大约 30 秒，会出现一条重复消息(至少根据 EnqueuedTime)。

所以问题是:有人经历过类似的事情吗？这可能是 Azure 本身的错误/时间问题吗？他们有任何保证不会发生这种情况吗？由于通话时间超过一分钟，我怀疑当时 Azure 中发生了某些事情，可能导致了这种情况(例如更新或类似的事情)

Answer 1

这种情况可能会发生，而且有点“正常”。服务总线 SDK 具有内部自动重试策略来克服暂时性错误。因此，如果第一次尝试成功，但由于网络问题导致响应丢失，它将重试并有效地传递消息两次。

It is possible for an error at the client or network level to occur a moment earlier, and for a sent message to be committed into the queue, with the acknowledgment not successfully returned to the client. This scenario leaves the client in doubt about the outcome of the send operation.

要解决此问题，您可以启用 Duplicate Detection有一定的间隔。这将防止在该时间间隔内发送重复的消息 ID。

有一个缺点:

Note that enabling duplicate detection and the size of the window directly impact the queue (and topic) throughput, since all recorded message-ids must be matched against the newly submitted message identifier.

理想情况下，您将拥有幂等接收器，这意味着它已准备好进行重复。但这并不总是可能/方便。