Azure函数应用触发选型：匹配同名不同类型Blob的最优方案

推荐方案：Azure Event Grid触发器 + 状态存储 #

这是最适配你场景的事件型方案，能完美解决文件上传顺序不确定的问题，同时保证实时性和高效性：

• 核心逻辑：通过Event Grid捕获所有Blob创建事件，结合状态存储记录文件对的存在状态，仅当一对文件（bin+flg）都已上传时才执行解密。
• 具体实现步骤：
  1. 给目标Blob存储容器配置Event Grid订阅，选择Microsoft.Storage.BlobCreated事件类型，将事件推送到你的函数应用。
  2. 函数接收事件后，解析Blob文件名，提取与配对文件对应的唯一标识（比如data001.bin和data001.flg的共同前缀data001）。
  3. 使用Azure Table Storage或Redis作为状态存储：
     • 若用Table Storage，可将PartitionKey设为文件前缀，RowKey设为文件类型（bin/flg），字段记录文件是否存在、是否已处理。
     • 若用Redis，可将键设为file-prefix:bin和file-prefix:flg，值设为exists或processed。
  4. 每次触发时，更新对应文件的状态，然后检查该前缀下的bin和flg是否都已标记为存在。
  5. 当两者都存在时，执行解密逻辑；完成后标记状态为已处理，避免重复执行。
• 优势：完全事件驱动，无轮询开销，能处理任意上传顺序的文件对，适合每日大量文件的场景。

Blob触发器的可行改进方案 #

如果坚持使用Blob触发器，可通过引入状态存储和延迟重试机制解决顺序问题：

• 核心调整：让Blob触发器监听所有bin和flg文件的创建事件，配合状态存储和延迟检查逻辑，确保不会遗漏文件对。
• 具体实现：
  1. 配置Blob触发器监听目标容器，触发条件设为所有.bin和.flg文件的创建。
  2. 同样用Table Storage或Redis记录文件对状态。
  3. 函数触发时，先检查配对文件是否存在：
     • 若配对文件不存在，将当前文件信息存入状态存储，同时向Azure Queue发送一条延迟消息（比如延迟5分钟），用于后续重新检查。
     • 若配对文件已存在，立即执行解密逻辑，完成后更新状态为已处理，并清理队列中对应的延迟消息（如果有的话）。
  4. 可选搭配Durable Functions：用Orchestrator函数编排等待逻辑，当收到一个文件的触发事件后，Orchestrator定期检查配对文件是否存在，直到两者齐全再执行解密活动函数。
• 注意事项：设置合理的重试次数和延迟间隔，避免无效重试；同时保证解密逻辑的幂等性（比如解密后将原文件移至归档容器），防止重复触发导致的异常。

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