.net - Azure 服务总线队列接收器是否有超时限制？

Question

我们正在从 Azure 服务总线队列接收消息。队列上的接收者(消息处理程序)调用应用程序服务，该服务更新 SQL 数据库表中的一百万多条记录，过程需要 30 多分钟。

Azure 服务总线队列有超时限制吗？这会导致 SQL 表进程停止更新行吗？

https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-get-started-with-queues

实际发送的服务总线消息队列非常小，只有Year和ProductType。然后应用程序服务方法将获取这两个参数，并更新整个sql表。

Azure 服务总线队列方法 ---> 服务总线消息接收(事件处理程序)---> 调用应用服务更新 SQL 表

Answer 1

简短回答:在 Peek-Lock 接收模式下，支持的最大锁定持续时间为 5 分钟。

现在是长答案:)

有 2 modes服务总线消息接收器的。

1. Peek-Lock 模式(非破坏性):如果您在创建 QueueClient 时未指定，则这是默认设置(constructor 具有接受 ReceiveMode 的重载)。在此模式下，接收会锁定/隐藏客户端的消息一段时间(称为锁定持续时间)，这是队列的设置(您可以在 Azure 门户中查看)。支持的最大值为5 分钟。如果此时您的处理尚未完成并且您未完成消息 (CompleteAsync)，则锁将过期并且消息将重新出现在队列中。更多详情请引用https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-transfers-locks-settlement#peeklock

对于长时间运行的操作，一种技术是 renew the lock间隔小于锁定持续时间。在下面的示例中，您可以在 MessageHandlerOptions 中设置 MaxAutoRenewDuration 属性，该属性可以为您自动续订。

另一种技术可以利用 Message deferral您可以在收到消息时开始处理，但继续推迟消息检索，直到处理完成，此时您收到消息并完成。有点复杂，但是一个聪明的方法。

接收和删除模式(破坏性):在此模式下，顾名思义，消息在接收时从队列中删除。因此您可以花很长时间进行处理。但问题是，如果您的客户端在处理过程中崩溃，您就有永远丢失消息的风险。