我想在我的Azure函数中实现一个非常简单的行为：如果在处理过程中出现异常，我想推迟下一次重试一段时间。据我所知，在服务总线中没有直接的可能性，例如（除非创建一条新消息），但服务总线触发器有可能ExponentialBackoffRetry.
我还没有找到任何有关服务总线连接如何工作的文档。 IE。函数执行失败后消息会发生什么情况。
一种可能的方法是将消息保留在功能基础设施中，并在我认为的持续时间内不断更新锁定。关于我想知道的一些更实际的问题：
- 我可以使用退避重试多长时间（例如，如果我想重试长达 7 天，例如这可行吗？）
- 当主机重置/重新启动/缩放时会发生什么，我是否会由于实现细节而失去此退避，或者它仍然以某种方式维护？
来自文档 https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages?tabs=csharp#using-retry-support-on-top-of-trigger-resilience:
在触发弹性之上使用重试支持
函数应用重试策略独立于触发器提供的任何重试或弹性。函数重试策略仅位于触发弹性重试之上。例如，如果使用 Azure 服务总线，默认情况下队列的消息传递计数为 10。默认传递计数意味着在尝试传递队列消息 10 次后，服务总线将使该消息成为死信。您可以为具有服务总线触发器的函数定义重试策略，但重试将分层在服务总线传输尝试之上。
例如，如果您使用默认的服务总线交付计数 10，并定义函数重试策略为 5。消息将首先出队，将服务总线交付帐户增加到 1。如果每次执行都失败，则在五次尝试触发后相同的消息，该消息将被标记为已放弃。服务总线会立即重新排队该消息，它将触发该函数并将传递计数增加到 2。最后，在 50 次最终尝试（10 次服务总线传递 * 每次传递 5 次函数重试）之后，该消息将被放弃并触发死机。服务巴士上的信。
对于指数重试，您可能需要将总退避时间+处理时间保持在小于函数可以保留消息的时间，否则锁将过期，甚至成功处理也会导致异常并重试。
从目前服务总线锁定消息的方式来看，Azure 服务总线上的指数退避并不是一个好主意。一旦持久终点成为可能（无限锁定时间，无需更新），这将更有意义。
Update：功能重试功能正在启用已弃用 https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-error-pages.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
