有没有办法可以延迟 Azure 函数中服务总线消息的重试？答案

【问题标题】：Is there a way I can delay the retry for a service bus message in an Azure function?有没有办法可以延迟 Azure 函数中服务总线消息的重试？
【发布时间】：2018-09-28 00:22:47
【问题描述】：

我有一个从订阅中提取消息并将它们转发到 HTTP 端点的函数。如果端点不可用，则会引发异常。发生这种情况时，我想将该特定消息的下一次尝试延迟一段时间，例如15分钟。到目前为止，我已经找到了以下解决方案：

捕获异常，休眠，然后抛出。这是一个糟糕的解决方案，因为我会在它处于休眠状态时收取 CPU 使用费，这会影响函数的吞吐量。
捕获异常，克隆消息，设置ScheduledEnqueueTimeUtc 属性并将其添加回队列。这是一种更好的方法，但它会重置传递计数，因此实际问题永远不会死信，并且当只有一个订阅者未能处理它时，它会重新发送给所有订阅。
捕获异常，并将消息放在存储队列中。这意味着要维护一个存储队列以匹配每个订阅，并拥有两个功能而不是一个。

我最理想的情况是捕获异常，然后退出函数而不释放消息上的锁。这样，一旦锁过期，消息将再次重试。但是，似乎成功完成后，该函数在消息上调用Complete()，并且在抛出异常后，该函数在消息上调用Abandon()。是否可以绕过这一点，或者以其他方式实现延迟？

【问题讨论】：

如果这些异常不经常发生，您可以创建一个带有计时器的函数，该计时器每 15 分钟触发一次并检查死信队列。

标签： c# azure-functions servicebus azure-servicebus-topics retry-logic

【解决方案1】：

我将通过提供 LogicApp 比纯函数更好地处理您提出的流程来解决您的情况。

在 LogicApp 中实现 wait/retry/dequeue next 模式非常容易，因为这种类型的流控制正是 LogicApps 的设计目标。

【讨论】：

是的，考虑到他们有一个HTTP 操作，可以让您在408、429 和5XX 返回代码上定义重试策略，这绝对看起来更像我所追求的.现在我需要弄清楚如何为授权标头和消息正文提取代理消息的部分

【解决方案2】：

虽然仍处于预览阶段（不推荐用于生产代码），但您可以使用 Durable Functions。如果您想保持在代码中操作对象的能力，这可能是您最好的选择！

（也为 LogicApp 解决方案+1！）

【讨论】：

【解决方案3】：

现在通过 retry policies 原生支持此功能，该功能于 2020 年 11 月左右添加到 Azure Functions（预览版）。您可以将重试策略配置为固定延迟或指数退避。

[FunctionName("MyFunction")]
[FixedDelayRetry(10, "00:15:00")]   // retries with a 15-minute delay
public static void Run(
    [ServiceBusTrigger("MyTopic", "MySubscription", Connection = "ServiceBusConnection")] string myQueueItem) 
{
    // Forward message to HTTP endpoint, throwing exception if endpoint unavailable
}

【讨论】：