Azure Function处理Blob多发票PDF：如何顺序处理避免SQL死锁

方案1：设置Blob触发处理的并发度为1（最快实现） #

如果用Azure Function这类无服务器服务处理Blob上传事件，直接修改配置限制并发数：

• 找到函数配置文件（比如function.json），将maxConcurrentCalls参数设为1。这样不管同时上传多少个PDF，函数同一时间只会处理一个文件，处理完当前任务再取下一个，从根源上避免并发写入SQL的冲突。
• 优点：零额外组件，改个配置就搞定，适合快速解决问题。
• 缺点：单个PDF处理耗时较长时，整体吞吐量会受影响，但能完全避免死锁和行排列异常。

方案2：用队列做串行缓冲 #

把Blob上传事件转成队列消息，用单消费者处理：

• 当Blob上传完成时，先触发一个轻量转发函数，仅将Blob的存储路径、文件名等关键信息写入Azure Storage Queue，不做实际解析和入库操作。
• 单独部署一个单实例的处理服务（或设置并发度为1的Azure Function），从队列里逐个拉取消息，依次调用Form Recognizer API解析PDF，再写入SQL。
• 优点：解耦上传事件和处理逻辑，队列可做消息持久化，就算处理服务挂了，重启后能继续处理未完成任务。
• 缺点：需要额外配置队列组件，但配置成本很低。

方案3：加分布式锁控制并发 #

如果不想大改现有架构，给处理逻辑加锁：

• 用Azure Redis或者SQL Server的应用锁实现全局锁：每次开始处理前，先尝试获取一个唯一命名的锁（比如InvoiceProcessingGlobalLock），获取成功才执行解析和入库操作，处理完成后立即释放锁。
• 如果获取锁失败，说明当前有其他进程在处理，直接将当前任务延后重试（比如用函数的重试机制）。
• 优点：无需大改现有代码，只需在处理逻辑前后加锁逻辑。
• 缺点：需要依赖Redis或SQL的锁机制，要处理锁超时、重试等边界情况。

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