Azure Service Bus队列重试时新消息无法处理的问题咨询

场景背景 #

我有一个Azure Service Bus队列，以及一个基于Python开发、从该队列接收消息的Function App。使用Postman向队列发送消息，Function App配置了如下函数级重试策略：

@app.retry(
    strategy="exponential_backoff",
    minimum_interval="00:05:00",
    max_retry_count=12,
    maximum_interval="23:59:59",
)

我在队列中添加若干无效消息测试重试功能，当前队列共有5条消息，其中4条处于等待状态，但Function App仅处理1条消息，且根据Application Insights日志显示，这条消息正在进行第9次重试。

我原本以为即使已有消息处于重试状态，新消息也会被Function App按顺序立即处理，现咨询：

1. 此场景下的默认行为是什么？
2. 是否有办法在已有消息重试时仍处理新消息？

同时附上队列属性截图、Function App处理记录截图、日志截图，以及host.json配置文件内容：

{
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    },
    "logLevel": {
      "default": "Information",
      "Azure.Core": "Warning",
      "Azure.Core.1": "Warning",
      "Azure.Identity": "Warning",
      "Azure.Messaging.ServiceBus": "Warning",
      "Host.Controllers.Host": "Warning"
    }
  },
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  },
  "concurrency": {
    "dynamicConcurrencyEnabled": true,
    "snapshotPersistenceEnabled": true
  }
}

问题解答 #

1. 默认行为解析 #

你遇到的是函数级重试与Service Bus消息锁定机制共同作用的结果：

• 你配置的@app.retry是Function App本地的函数级重试，并非Service Bus队列原生的重试。当消息被拾取后，若处理失败，函数会在当前实例内按照指数退避策略重复执行，不会将消息放回队列。
• 在函数重试过程中，Service Bus触发器会自动续期这条消息的锁，确保其他消费者无法拾取。同时，当前Function实例会被这条重试消息持续占用，若只有单个实例，队列中其他等待的消息就无法被处理——这就是为什么你看到4条消息处于等待状态，而Function App仅在处理那一条重试消息。

2. 实现重试时同时处理新消息的方案 #

方案1：改用Service Bus队列原生重试（推荐）

放弃@app.retry配置，依赖Service Bus队列本身的重试机制：

• 在Service Bus队列属性中设置最大传递次数（对应你设置的max_retry_count=12）。
• 配置消息不可见间隔，让处理失败的消息自动回到队列并设置下次可见时间，而非在函数内重试。
• 函数处理失败时直接抛出异常，Service Bus会自动将消息放回队列（达到最大重试次数后进入死信队列）。
  这种方式下，函数处理失败后会立即释放消息锁，消息进入不可见状态，函数实例可以立即拾取队列中的其他等待消息。

方案2：调整并发配置提升处理能力

若坚持使用函数级重试，可通过提升并发数让多个实例/线程处理消息：

• 在host.json中添加Service Bus触发器的并发配置：

{
  "version": "2.0",
  // 保留原有配置...
  "extensions": {
    "serviceBus": {
      "maxConcurrentCalls": 10, // 每个实例的并发调用数，默认1
      "prefetchCount": 20 // 预取消息数，优化吞吐量
    }
  }
}

• 开启Function App的弹性缩放，让平台根据负载自动增加实例数量。即使某个实例被重试消息占用，其他实例仍可处理队列中的等待消息。

方案3：自定义重试逻辑，避免长时间锁占用

在函数内部实现有限次数的本地重试，超过次数后主动放弃消息：

• 使用第三方库（如tenacity）实现自定义重试逻辑，而非依赖@app.retry。
• 当本地重试达到设定次数后，抛出异常让消息回到队列并设置可见间隔，释放锁以处理新消息。

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