Azure Service Bus是否可能创建了该消息的副本？ [英] Is it possible that Azure Service Bus created a duplicate of the message?

问题描述

我们在Azure Service Bus中遇到了一些奇怪的行为，除了Azure中的某个错误之外，我们不知道如何解释。事情是这样的：

1. 我们已向Azure Service Bus发送过一次消息
2. 执行发送消息的调用花了一分钟多一点的时间，但还是成功了，之后消息接收正常
3. 大约半秒后出现重复消息，EnqueuedTimeUtc和SequenceNumber与第一条消息不同，但它具有与我们生成的相同的内容和MessageId

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

我们也不认为这是执行此操作的客户端库，因为在出现在总线上的这两条消息之间还发送了其他消息，我认为客户端库不会在后台执行此操作，同时允许其他消息通过。不过，这一点并不是100%确定的。以下是我们计算出的结果：

1. 发送第一封邮件
2. 该操作需要大约63秒才能完成
3. 之后会发送一些其他消息
4. 在发送第一条消息大约30秒后出现重复项(至少根据入队时间)。

所以问题是：有没有人经历过类似的事情，这会不会是Azure本身的错误/临时问题，他们能保证这种情况不会发生吗？由于呼叫进行了一分钟，我怀疑当时Azure中发生了什么事情，可能导致了它(例如更新或类似的事情)

推荐答案

这种情况可能会发生，这是一种"正常"现象。Service Bus SDK具有内部自动重试策略，以克服瞬时错误。因此，如果第一次尝试成功，但由于网络问题导致响应丢失，它将再次尝试并有效地传递两次消息。

客户端或网络级别的错误可能会提前发生，发送的消息可能会被提交到队列中，但确认不会成功返回给客户端。此方案使客户端无法确定发送操作的结果。

要解决此问题，可以按一定间隔启用Duplicate Detection。这将防止在此间隔内发送重复的邮件ID。

有缺陷：

请注意，启用重复检测和窗口大小将直接影响队列(和主题)吞吐量，因为所有记录的消息ID都必须与新提交的消息标识符相匹配。

理想情况下，您应该有一个幂等接收器，这意味着它已为复制做好准备。但这并不总是可能/方便的。

这篇关于Azure Service Bus是否可能创建了该消息的副本？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！