Azure 服务总线 .net SDK 是否会传递重复的消息？
我目前正在使用 Azure.Messaging.ServiceBus .net SDK 按照 ASB 标准批量发送高吞吐量消息。在通过在高吞吐量批量发送期间关闭互联网来模拟间歇性网络连接情况时，我们观察到有一些额外的消息传递到了 ASB。在 ASB 门户中观察到的队列计数与我们的日志不匹配。 ASB 会发生这种情况吗？请注意，我们已启用为客户端启用的重试策略。我遇到了类似的 StackOverflow 线程并想知道是否有任何与此相关的最新进展。
I am currently using Azure.Messaging.ServiceBus .net SDK to send high throughput messages in batches to ASB standard. While simulating an intermittent network connectivity situation by turning off the internet during a high throughput batched send, we observed that there were some extra messages delivered to the ASB. The count observed in the ASB portal for the queue didn't match our logs. Can this happen with the ASB? Note that we have enabled retry policies enabled for the client. I came across a similar StackOverflow thread and want to know if there is any latest progress pertaining to this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的;服务总线保证至少一次。当发布因不明确的状态而失败并重试时，可能会出现重复。使用重复检测功能可以帮助防止这种情况，但要求您的应用程序负责分配唯一的
MessageId值。如果收到消息但未解决，也可能会发生重复。一旦其锁定过期，该消息就有资格再次被接收。
接收消息的应用程序应确保处理是幂等的，并且任何所需的重复检测或防护都已到位。
Yes; the Service Bus guarantee is at-least-once. Duplicates are possible when publishing fails with an ambiguous state and is retried. Using the duplicate detection feature can help to guard against this, but requires that your application take responsibility for assigning unique
MessageIdvalues.Duplicates can also occur if a message is received and is not settled. Once its lock has expired, the message is eligible to be received again.
Applications receiving messages should ensure that processing is idempotent and any needed detection or guards for duplicates are in place.