Azure Functions Service Bus触发器：可配置持久化延迟重试方案问询

核心需求 #

实现基于Service Bus触发器的Azure Functions对失败消息的延迟重试，解决默认抛出异常后消息被立即重新处理的问题。

现有方案的局限性 #

1. 使用FixedDelayRetryAttribute的问题 #

• 重试次数、延迟时长需硬编码，无法通过配置中心动态调整；
• 主机重启/缩容后，未完成的重试状态会丢失，重启后无法继续原有重试流程；
• 框架内部重试不计入Service Bus的消息投递次数，容易造成统计混淆（例如重试3次失败仅被计为1次ASB投递）。

2. 手动处理消息（AutoCompleteMessages=false）的问题 #

尝试通过消息锁过期或续锁实现延迟，但框架要求必须对消息显式执行完成、死信或延迟操作，否则仍会自动放弃消息。调用RenewMessageLockAsync()或不做任何操作，最终都会导致消息被立即重新投递。

当前最优实现方案 #

通过完成原消息，同时新建一条带计划投递时间的消息来实现延迟重试，以下是优化后的代码示例（增加重试次数跟踪，防止无限循环）：

[FunctionName("MyFunc")]
public async Task MyFunc(
    [ServiceBusTrigger("MyQueue", AutoCompleteMessages = false)] ServiceBusReceivedMessage message,
    [ServiceBus("MyQueue")] IAsyncCollector<ServiceBusMessage> collector,
    ServiceBusMessageActions messageActions,
    CancellationToken token)
{
    // 从消息属性中获取当前重试次数，默认0
    var retryCount = message.ApplicationProperties.TryGetValue("RetryCount", out var count) 
        ? (int)count 
        : 0;
    
    // 设定最大重试次数，可从配置读取
    const int maxRetries = 3;

    try
    {
        // 业务逻辑处理
        // do work...
        await messageActions.CompleteMessageAsync(message, token);
    }
    catch
    {
        if (retryCount >= maxRetries)
        {
            // 达到最大重试次数，死信消息
            await messageActions.DeadLetterMessageAsync(message, "Max retries reached", "Exceeded allowed retry attempts", token);
            return;
        }

        // 完成原消息，避免重复处理
        await messageActions.CompleteMessageAsync(message, token);
        
        // 新建延迟消息，递增重试次数并保留关联ID
        var retryMessage = new ServiceBusMessage(message.Body)
        {
            ScheduledEnqueueTime = DateTimeOffset.UtcNow.AddMinutes(1),
            CorrelationId = message.CorrelationId
        };
        retryMessage.ApplicationProperties["RetryCount"] = retryCount + 1;
        
        await collector.AddAsync(retryMessage, token);
        await collector.FlushAsync(token);
    }
}

替代思路探讨 #

如果希望避免创建新消息，可尝试使用ServiceBusMessageActions.DeferMessageAsync()将消息延迟，但该方法仅会暂时隐藏消息，不会自动重回队列，需额外实现逻辑（如定时任务或专用函数）根据消息的SequenceNumber重新接收处理，复杂度较高，适合对消息唯一性要求极高的场景。

内容的提问来源于stack exchange，提问作者axk