我想在我的Azure函数中实现一个非常简单的行为:如果在处理过程中出现异常，我想推迟下一次重试一段时间。据我所知，在服务总线中没有直接的可能性，例如(除非创建一条新消息)，但服务总线触发器有可能进行ExponentialBackoffRetry。
我还没有找到任何有关服务总线连接如何工作的文档。 IE。函数执行失败后消息会发生什么情况。
一种可能的方法是将消息保留在函数基础设施中，并在我认为的持续时间内不断更新锁定。关于我想知道的一些更实际的问题:
- 我可以使用退避重试多长时间(例如，如果我想重试长达 7 天，这样可以吗？)
- 当主机重置/重新启动/扩展时会发生什么情况，我是否会因为实现细节而失去此退避，或者它仍然以某种方式维护？
最佳答案
来自documentation :
Using retry support on top of trigger resilience
The function app retry policy is independent of any retries or resiliency that the trigger provides. The function retry policy will only layer on top of a trigger resilient retry. For example, if using Azure Service Bus, by default queues have a message delivery count of 10. The default delivery count means after 10 attempted deliveries of a queue message, Service Bus will dead-letter the message. You can define a retry policy for a function that has a Service Bus trigger, but the retries will layer on top of the Service Bus delivery attempts.
For instance, if you used the default Service Bus delivery count of 10, and defined a function retry policy of 5. The message would first dequeue, incrementing the service bus delivery account to 1. If every execution failed, after five attempts to trigger the same message, that message would be marked as abandoned. Service Bus would immediately requeue the message, it would trigger the function and increment the delivery count to 2. Finally, after 50 eventual attempts (10 service bus deliveries * five function retries per delivery), the message would be abandoned and trigger a dead-letter on service bus.
对于指数重试，您可能需要将总退避时间+处理时间保持在小于函数可以保留消息的时间，否则锁定将过期，甚至成功处理也会导致异常并重试。
就目前服务总线锁定消息的方式而言，Azure 服务总线上的指数退避并不是一个好主意。一旦持久终点成为可能(无限锁定时间，无需更新)，这将更有意义。
更新:函数重试功能正在 deprecated .
关于azure - ExponentialBackoffRetry 如何与 Azure 函数的 ServiceBus 触发器配合使用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/67869677/