Azure QueueTrigger函数遇异常时队列行为机制咨询

刚好对Azure Queue触发的Function这个场景熟得很，给你详细拆解下：

默认情况下，当你的函数因为FTP服务器不可访问抛出未处理异常时，消息不会被直接丢弃，而是会进入内置的重试逻辑，具体行为是这样的：

• 自动放回队列并延迟重试：函数执行失败后，这条消息不会被删除，而是会被重新放回队列，但会设置一个「隐藏时间」——也就是这段时间内其他函数实例看不到这条消息，避免立刻重复触发。而且每次重试的隐藏时间会默认按指数递增（比如第一次等10秒，第二次20秒，以此类推），防止短时间内疯狂重试给系统造成压力。
• 重试上限与死信队列：当这条消息被反复取出处理失败，达到设定的「最大取出次数」（默认是5次，可自定义）后，它就会被移到对应的死信队列（Dead-letter Queue），不会再被正常的函数触发处理。死信队列里的消息可以留着后续排查问题，或者用专门的逻辑去处理。
• 自定义重试规则：你完全可以通过host.json文件来定制重试策略，比如调整重试次数、延迟间隔、退避方式。举个常见的配置例子：

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "maxDequeueCount": 8,
      "retry": {
        "maxRetryCount": 6,
        "delay": "00:00:15",
        "maximumDelay": "00:03:00",
        "backoffType": "exponential"
      }
    }
  }
}

这里maxDequeueCount控制消息被取出的最大次数，超过就进死信；retry段里的参数分别设置了最大重试次数、初始延迟、最长延迟，以及用指数退避的方式增加间隔。

• 关键提醒：如果你的函数里手动捕获了异常却没有重新抛出，Azure会判定这条消息处理成功，直接从队列里删除——哪怕你实际没完成FTP下载。所以要让队列触发重试，一定要让异常冒泡出去，别把它吞了。

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