Azure功能扇出/扇入，无持久功能

我有两个按顺序运行的Azure队列触发器，一个是WebJob，另一个是Azure函数。第一个队列触发器生成大量由第二个队列触发器拾取的消息。问题是，第一个队列触发器生成了一个blob，第二个队列触发器会全部使用该blob，我想在第二个队列触发器全部完成后删除该blob

最明显的解决方案是使用扇出/扇入设计模式将队列转换为持久功能，但我更愿意避免这种情况，因为队列为我提供了自动重试/中毒队列，并且已经设置好并使用其他现有代码运行，在第二个队列全部完成后不需要删除blob

我已经提出了一些可能的解决方案，但希望得到反馈，因为我对Azure功能和WebJobs还比较陌生。它们基本上都使用变通方法异步计算第二个队列触发器的完成情况，并在最后一个队列触发器完成时从第二个队列触发器中删除blob

解决方案1：

让第一个队列触发器创建一个临时队列。在将原始队列消息添加到第二个队列之前，请将与原始队列消息相同数量的队列消息添加到临时队列。每次第二个队列触发器处理完一条原始消息后，从临时队列中取出一条消息。从临时队列中退出最后一个项目后，删除blob和临时队列

解决方案2：

在存储帐户中创建一个表。在将队列消息添加到第二个队列之前，请在表中插入一行，其中包含blob名称和消息总数。在第二个队列触发器完成对其中一条消息的处理后，插入一个具有blob名称的行。插入的行数等于计数后，删除blob和表行

我还提出了其他可能的解决方案，例如使用Redis缓存而不是存储帐户中的表，或者在一段时间后删除临时文件而不是试图计算完成的次数，但上述两种解决方案似乎是迄今为止最有希望的

---

有更多使用Azure函数和WebJobs经验的人有什么建议吗？

解决方案2与持久函数在幕后的作用非常相似，因此它可以工作，但实现和调试的负担由您承担。您可能会遇到一些并发性问题、处理重试时的不确定性等。如果您的解决方案不需要非常健壮，请尝试

如果问题只是删除blob文件，我可以想象一个更简单的解决方案。例如，发送另一封邮件（延迟1小时）以删除该邮件，而您知道自己的处理时间总是少于1小时。或者只是定期清理旧文件

---

我怀疑是否存在一个替代的、琐碎的、正确的扇入解决方案。

我最终选择了解决方案1，我的测试似乎表明它是有效的。我很欣赏这一见解。出现的主要问题是，我需要使用DeleteIfExists（）删除blob，而不是在出现竞争条件时仅删除（）。