Azure Function（Service Bus Trigger）处理大文件时重复运行问题求助

核心可能原因拆解 #

1. 会话锁续约失败（而非普通消息锁） #

你使用的是启用会话的Service Bus队列，这类队列的锁机制和普通队列存在差异：当函数处理会话中的消息时，不仅要持有单条消息的锁，还要持有整个会话的锁。maxAutoRenewDuration配置主要针对消息锁的自动续约，但会话锁的续约依赖于函数Runtime的心跳机制——如果处理大量Excel时主线程被长时间阻塞（比如大文件IO、内存密集型操作），Runtime可能无法及时发起会话锁的续约请求，导致会话锁提前过期。

一旦会话锁过期，Service Bus会判定当前会话处理中断，将会话内未完成的消息重新标记为可消费状态，触发函数再次执行，这就是你看到的重复运行现象。而添加12分钟延迟后，处理时间在会话锁的有效续约窗口内，所以未出现异常。

2. 内存压力导致进程被静默回收 #

Premium计划的函数实例有固定内存限制（比如P1v2规格为2GB），合并大量Excel属于内存密集型操作：加载多份Excel文件到内存时，内存占用会快速飙升。当内存使用率接近阈值时，Azure宿主环境可能会强制静默回收进程——这种回收是无预警的，函数没有机会完成消息处理、上报错误日志，也无法主动释放锁或标记消息完成。

此时Service Bus会因消息锁/会话锁超时，将消息重新投递（尽管你设置了最大传递次数为1，但如果是会话锁过期导致消息回流到会话队列，可能触发再次消费，直到消息达到传递次数上限后进入死信队列）。你未收到错误日志，正是因为进程被强制回收，日志来不及写入或上报。

验证与解决建议 #

验证方向 #

• 查看函数实例的内存监控数据：在Azure门户的函数应用监控面板中，查看内存使用率趋势，确认处理大量Excel时是否出现接近实例内存上限的峰值。
• 检查Service Bus的死信队列：如果消息达到最大传递次数，会进入死信队列，以此判断是否是重复投递导致的函数重复执行。
• 开启函数详细日志追踪：在host.json中将logging.logLevel配置为Information或Debug，重点查看会话锁续约相关的日志条目（如Session lock renewed或Session lock expired）。

解决方案 #

• 优化Excel合并的内存占用：避免一次性加载所有Excel文件到内存，改用流式处理或分批读取；使用轻量级Excel处理库的低内存模式（如EPPlus的LoadFromText流式读取）。
• 调整会话锁配置：在host.json中明确配置Service Bus Trigger的会话锁参数（如sessionIdleTimeout），确保续约时长覆盖最长处理时间。
• 升级实例内存规格：若确认是内存不足，升级Premium计划的实例规格（如从P1v2升级到P2v2），提升内存上限。
• 主动管理会话锁：在代码中手动控制会话的开启与关闭，处理完成后及时调用Session.CloseAsync()释放会话锁，避免长时间持有锁资源。

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