Azure 服务总线向队列中添加消息的速度过快答案

【问题标题】：Azure Service Bus adding message to the queue too quicklyAzure 服务总线向队列中添加消息的速度过快
【发布时间】：2021-12-30 01:25:26
【问题描述】：

我遇到了一个问题，我触发了由 Azure Function Service Bus Trigger 处理的事件。

运行的触发器最多可以运行一个小时，这很好，但我发现 5 分钟后消息会重新添加到队列中，因此会重复处理。

我可以通过更改 MaxDeliveryCount 确保此特定主题仅读取一次消息来解决此问题，但理想情况下，我希望锁的到期时间比函数长（最多 1 小时）。

根据 Microsoft 文档，它应该已经这样做了，但是当它重新排队消息时我仍然遇到问题。

函数运行时在 PeekLock 模式下接收消息。如果函数成功完成，它会在消息上调用 Complete，如果函数失败，它会调用 Abandon。如果函数运行时间超过 PeekLock 超时时间，只要函数运行，锁就会自动更新。

有什么想法吗？

【问题讨论】：

标签： c# azure azureservicebus azure-servicebus-topics azure-servicebus-subscriptions

【解决方案1】：

Azure 服务总线一次最多只能锁定一条消息 5 分钟。但它也可以更新锁，从技术上讲，只要没有发出锁定请求的失败，它就可以允许消息被锁定只要需要。除此之外，execution time 函数可以有一个限制。例如，在消耗计划中，函数的运行时间不会超过最长 10 分钟。对于任何超过此时间的处理，应寻找替代方案，包括但不限于以下内容：

功能高级版
应用服务
容器（Container Apps Service 看起来很有前途）

【讨论】：

这是一个持久的函数，所以它应该能够运行只要需要。问题是，我如何自动更新锁，或者这是 Azure 在他们这边做的事情？
持久功能不是魔法。而且它不是免费的，没有任何限制。所以我高度怀疑你对执行时间的假设。尽管如此，host.json 是您指定最大锁定更新值的地方。
所以我看到的唯一选项是“maxAutoRenewDuration”。文档说“消息锁定将自动更新的最大持续时间。”。那么这是否意味着我指定这个时间低于锁定时间或函数的最大运行时间？抱歉，我是 Service Bus 的新手，但我非常感谢您的帮助
其实我觉得这个评论解释的很好。 github.com/Azure/azure-functions-host/issues/…
是的。您始终将“重新锁定”设置为比传统的最大锁定持续时间长。否则就没有意义了。