我有两个顺序运行的Azure队列触发器，一个是WebJob，另一个是Azure函数。第一个队列触发器生成许多消息，这些消息被第二个队列触发器获取。问题在于，第一个队列触发器生成了一个blob，第二个队列触发了所有blob，我想在第二个队列触发所有完成后删除该blob。
最明显的解决方案是使用扇出/扇入设计模式将队列转换为持久功能，但是我宁愿避免这种情况，因为队列为我提供了自动重试/中毒队列，并且已经设置好了，在第二个队列全部结束后，无需删除blob即可与其他现有代码一起运行。
我已经提出了一些潜在的解决方案，但是希望获得反馈，因为我对Azure Functions和WebJob还是比较陌生。它们本质上都使用变通办法来异步计数第二个队列触发器的完成，并在最后一个触发器完成时从第二个队列触发器中删除blob。
解决方案1：
让第一个队列触发器创建一个临时队列。在将原始队列消息添加到第二个队列之前，请向临时队列添加与原始队列消息相同数量的队列消息。每次第二个队列触发器完成对原始消息之一的处理后，请从临时队列中取出消息。将最后一个项目从临时队列中出队后，删除Blob和临时队列。
解决方案2：
在存储帐户中创建一个表。在将队列消息添加到第二个队列之前，在表中插入一个带有Blob名称和总消息计数的行。在第二个队列触发器完成对其中一条消息的处理之后，插入带有Blob名称的行。在插入的行数等于计数之后，删除Blob和表行。
我还提出了其他可能的解决方案，例如使用Redis缓存而不是存储帐户中的表，或者在一段时间后删除临时文件，而不是尝试计算完成次数，但是到目前为止，以上两种解决方案似乎是最有希望的。
对使用Azure Functions和WebJob有更多经验的人有什么建议吗？
答案 0 :(得分：0)
解决方案2与持久功能在幕后的工作非常相似，因此，它可以工作，但是实现和调试的负担在您身上。您可能会遇到一些并发问题，处理重试时的不确定性等。如果您的解决方案不需要非常强大，那就继续吧。
如果问题只是删除blob文件，我可以想象一个更简单的解决方案。例如。发送另一个消息，例如删除它需要1小时，而您知道您的处理时间始终少于一小时。或者只是定期清理旧文件。
我怀疑扇入是否存在替代且微不足道的正确解决方案。