Azure Blob Trigger函数使用System.Threading.Sleep出现调用丢失问题求助

• 执行时长超出平台限制：Azure Functions消费计划默认执行超时时间为5分钟，最大可配置为10分钟，你的单函数最大执行时长超过1小时，远超出消费计划的限制，平台会主动终止超时的执行实例，直接导致调用丢失。就算你用的是弹性Premium计划或专用计划，未正确配置超时阈值的情况下也会触发平台回收逻辑。
• 阻塞调用导致线程池耗尽：System.Threading.Sleep是同步阻塞调用，会长期占用函数运行的线程池资源，当并行调用量升高时，线程池快速耗尽，新的触发请求排队超时被平台丢弃，正在执行的请求也会因为资源不足无法调度，表现为卡在Sleep调用处无法返回。
• 实例回收无状态保留：消费计划下Azure Functions会根据负载动态增减实例，休眠中的实例被回收时，正在运行Sleep的调用不会被通知也不会保留执行上下文，直接中断导致调用丢失，且不会留下异常日志。

推荐方案：使用Durable Functions重构长时任务 #

Durable Functions是Azure Functions原生支持的长时工作流框架，专门解决这类需要长时间等待的场景：

• 用持久定时器替代System.Threading.Sleep，等待期间函数实例会被平台释放，不占用任何计算资源，2分钟等待时间到后自动唤醒实例继续执行，完美支持小时级的长时任务。
• 工作流拆分逻辑：
  1. Blob触发函数作为客户端，启动传真处理Orchestrator
  2. Orchestrator调用发送传真的活动函数
  3. Orchestrator创建持久定时器等待2分钟
  4. 唤醒后调用传真状态检查活动函数
  5. 若传真发送完成则结束工作流，未完成且未到30次检查上限则回到步骤3继续循环
• 该方案无需手动管理执行状态，平台自动持久化工作流上下文，即使实例回收也不会丢失执行进度。

临时适配方案：调整配置+替换阻塞调用 #

如果暂时无法重构代码，可通过以下修改缓解问题：

1. 更换托管计划：将消费计划切换为弹性Premium计划或专用App Service计划，配置函数超时时间≥60分钟，满足最长执行时长要求。
2. 替换阻塞调用：将System.Threading.Sleep(120000)替换为非阻塞的await Task.Delay(120000)，避免长期占用线程池资源，同时Task.Delay可响应平台的终止信号，优雅退出避免异常丢失。
3. 限制并行度：在host.json中配置Blob触发器的最大并行调用数，避免瞬时大量触发导致资源耗尽。

兜底可靠性优化 #

无论采用哪种方案，都建议补充以下机制避免调用丢失：

• 配置Blob触发器的死信队列，超过最大重试次数的触发消息会被转发到死信队列，可后续手动或自动重试处理。
• 用Azure Table Storage/Redis等持久化存储记录每次传真的检查进度，即使执行中断，重试时可直接从上次检查的位置继续执行，无需从头开始循环。

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