Azure Functions Blob触发器如何实现多Blob顺序处理避免并发异常

一、纯配置实现严格串行（适合低吞吐场景） #

直接通过配置锁死单实例、单并发执行，无需改动业务代码：

• 调整函数应用host.json配置，从触发器调度层限制并行度，5.x版存储扩展配置参考如下：

{
  "version": "2.0",
  "extensions": {
    "blobs": {
      "maxDegreeOfParallelism": 1
    },
    "queues": {
      "batchSize": 1,
      "newBatchThreshold": 0
    }
  }
}

配置说明：

• maxDegreeOfParallelism: 1：控制单个函数实例同一时间最多只处理1个Blob
• batchSize: 1 + newBatchThreshold: 0：Blob Trigger底层依赖存储队列做事件调度，这组参数控制队列每次只拉取1条待处理消息，当前消息处理完成前不会拉取新消息
• 限制函数应用横向扩展实例数：进入函数应用「配置-横向扩展」设置页，将最大实例数手动设为1，避免平台自动扩容出多个实例并行拉取Blob处理。
  该方案的缺点是吞吐量极低，仅适合每小时Blob新增量在百级以内、对处理时延不敏感的场景。

二、架构改造实现可靠串行（适合中高吞吐场景） #

纯配置方案在Blob量较大时容易出现消息乱序、处理积压，可通过拆分触发器和处理逻辑实现更可靠的顺序执行：

• 拆分原有Blob Trigger逻辑：保留的Blob Trigger仅做轻量转发，新Blob触发后不直接执行业务解析，仅将Blob的元信息（容器名、Blob名称、上传时间戳、ETag）按上传先后顺序写入专用存储队列/服务总线队列。
• 新增独立的队列触发函数：将该队列触发器的并发度设为1、最大实例数锁1，严格按队列先进先出的顺序拉取Blob元信息，执行文件解析、数据库写入的核心业务逻辑。
• 乱序兜底逻辑：队列消费时校验Blob的上传时间戳，若当前拉取到的Blob上传时间早于最近一次处理完成的Blob时间，说明出现消息乱序，将当前消息重新投递回队列延迟30秒再消费，确保严格按上传顺序处理。

三、数据库侧兜底配置（必加，避免偶发异常） #

不管采用上述哪种串行方案，都建议在数据库层做冲突防护，从根本上避免主键冲突、重复写入问题：

• 替换普通INSERT语句为UPSERT逻辑：根据业务主键做判断，记录已存在则执行更新，不存在则执行插入，不同数据库可使用对应语法实现：
  • PostgreSQL：INSERT ... ON CONFLICT(主键字段) DO UPDATE SET ...
  • MySQL：INSERT ... ON DUPLICATE KEY UPDATE ...
  • SQL Server：使用MERGE语句实现存在则更新、不存在则插入
• 增加重复处理校验：解析Blob写入数据库前，先比对Blob的ETag和数据库中记录的对应文件最后处理的ETag，若一致说明该Blob已经处理完成，直接跳过即可，避免重复写入。
• 核心表加行级排他锁：写入同主键对应的数据前先加锁，就算出现极偶发的并发请求，也会等待锁释放后再执行，不会直接抛出主键约束冲突异常。

补充说明：如果业务不需要严格的全局顺序，仅要求同一个业务主键对应的数据不出现并发写入冲突，无需强行配置全局串行。可按业务主键对Blob做分区，同一分区内串行处理、不同分区并行处理，通过服务总线会话模式即可实现，吞吐量远高于全局串行方案。

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